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ABSTRACT 


This thesis analyzed the principles and concepts of Marine Aviation Logistics 
doctrine at the tactical level and the current Information Management Systems used to 
execute mission requirements. A web-enabled prototype for Marine Aviation Logistics 
Squadrons (MALS) was developed to optimize management and decision support for 
deliberate, time sensitive and crisis action planning of aviation support operations. The 
first iteration of the prototype was tested by two Operations (S-3) Officers formerly 
assigned to active-duty Marine Aviation Logistics Squadrons (MALS). The application 
was also subjected to a usability experiment at the Database and Web Technologies Lab 
at the Naval Postgraduate School. The results of this research revealed potential benefits 
for tactical-level aviation logistics planners and sustainers; the prototype is a viable 


concept, worthy of future development. 
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I. INTRODUCTION 


This chapter discusses the Marine Aviation Logistics Squadron (MALS), the 
doctrine for aviation logistics, and the information management systems currently used to 
accomplish the mission. The chapter then discusses the objectives, expected benefits, 


methodology, and organization of the remaining chapters of this thesis. 


This chapter is organized as follows. Section A is the background information for 
the MALS, the Marine Aviation Logistics Support Program (MALSP) and _ the 
information management systems that MALS is currently using to execute mission 
requirements. Section B justifies this academic endeavor by pointing out the acute 
problems of the current information management systems. Section C discusses the 
objectives and broad system requirements for the prototype to be developed; Section D 
provides six ways tactical-level aviation logistics will be optimized by a web-centric 
application; Section E introduces the various methodologies used to analyze doctrine, and 
develop and test the web-enabled prototype; and Section F is a brief description of the 
remaining chapters of the thesis. 


A. BACKGROUND 
1. Marine Aviation Logistics Squadron 


United States Marine Corps Aviation Logistics at the tactical level is the 
responsibility of the Marine Aviation Logistics Squadron (MALS). There are 11 active 
duty MALS units supporting 71 tactical flying squadrons and 28 non-flying squadrons. 
MALS directly supports the tactical flying squadrons of the Marine Air Ground Task 
Force (MAGTF), Air Combat Element (ACE) by providing intermediate-level 
maintenance, supply and ordnance support for aircraft and aeronautical equipment [1]. 
The role of the MALS cannot be underestimated; they are the essential link of Marine 
Aviation Logistics support that enhances combat readiness of the MAGTF ACE and 


provides the sustainment necessary for continuous combat operations. 





oS 


Figure 1. Levels of Aviation Logistics 





Marine Aviation Logistics Squadrons vary in size, ranging between 600-800 
Marines and Sailors. The organizational structure of MALS consists of Headquarters, 
Maintenance, Supply, and Aviation Information Systems Departments. Headquarters is 
similar to other aviation units with having a Commanding Officer, Executive Officer, 
Administrative, Operations, and Logistics Department. However, the focus of effort and 
most of the work performed by MALS is done by the Maintenance and Aviation Supply 


Departments. 


The MALS Maintenance Department’s core functions include repair support to 
aircraft, aviation support equipment, avionics, flight equipment, cryogenics, aviation 
ordnance, and maintenance data collection and analysis [1]. As an intermediate-level 
maintenance activity, MALS maintenance is_ responsible for monitoring all 
organizational-level maintenance programs of the tactical flying squadrons assigned to 
the Marine Aircraft Group (MAG). This oversight task protects the quality assurance of 


maintenance practices and ultimately leads to increased combat readiness. 


The MALS Aviation Supply Department’s core functions include the inventory, 
storage and management of aviation logistics material. MALS Supply is responsible for 
providing technical research for needed aircraft repair parts and material, maintaining and 
reporting financial data for aviation material for the MAG, and monitoring, expediting, 
storing, issuing, and delivering parts and material that have been requisitioned [1]. The 
Aviation Supply Department is a multi-million dollar facility, organized to provide 
focused logistics support to sustain combat operations of tactical flying squadrons and the 


intermediate-level repair capability of the MALS Maintenance Department. 
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The MALS Operations Department is responsible for identifying, planning, 
reviewing, coordinating and supervising all tactical-level aviation logistics necessary to 
support operational requirements for exercises, contingencies and other concepts of 
operations [1]. To execute these core functions and properly tailor support, continuous 
coordination is required internally with the MALS Maintenance and Supply Departments. 
Externally, however, the MALS Operations Department is the link between the MAG and 
tactical flying squadrons to ensure the appropriate level of aviation logistics support is 
incorporated in all deliberate, time sensitive and crisis action planning. 


pe Marine Aviation Logistics Support Program 


The Marine Aviation Logistics Support Program (MALSP) is the current doctrine 
used to rapidly deploy and sustain a task-organized MAGTF ACE. The MALSP is based 
on people, repair parts, support equipment and mobile maintenance facilities. Together, 


they form the essential “building blocks” for tailored aviation logistics support. 
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Figure 2. MALSP Building Blocks [From: 1] 


Each MALS is designed to support Fixed Wing (FW) and/or Rotary Wing (RW) 
aircraft. However, mission requirements often require a mixed FW/RW aircraft 
composition, which necessitates the use of support capabilities from more than one 
MALS. To facilitate responsive and effective support across various Type/Model/Series 
(T/M/S) aircraft, standardized Contingency Support Packages (CSP) are maintained at 
each MALS consisting of a Common Contingency Support Package (CCSP), Peculiar 
Contingency Support Package (PCSP), Fly-In Support Package (FISP), Follow-On 
Support Package (FOSP) and ‘Training Squadron Allowance (TSA). These 
predetermined packages give the MAGTF Commander the flexibility to mix and match 
T/M/S aircraft with the required aviation support. 


In the event of a major operation or contingency where a tailored ACE is 
required, a host MALS 1s identified and marshals their Common Contingency Support 
Package. The host MALS will also provide any Peculiar Contingency Support Packages 
organic to their MAG that matches the T/M/S aircraft mix of the proposed ACE. Non- 
organic Peculiar Contingency Support Packages, however, are provided by another 
MALS. These CSPs are then airlifted or embarked on Aviation Logistics Support Ships 
(T-AVB). The U.S. Maritime Administration provides the Military Sealift Command 
with two T-AVBs, dedicated to support movement of aviation logistics ashore, or to 
establish a “floating” intermediate-level aviation logistics activity offshore. The CCSP is 
viewed as the foundation of support, while the PCSP is viewed as load-bearing pillars of 


the aviation logistics support structure [1]. 
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Figure 3. ©.MALSP Employment [From: 1] 


The remaining MALSP CSPs are the FISP and FOSP. The FISP is reserved stock 
for a time of war; therefore, it is always maintained at or near 100% stock allowances. 
The FISP consists of spare parts that are normally removed and replaced at the 
organizational (tactical flying squadron) level. The FISP is built to logistically sustain 
the initial 30 days of combat operations; meaning, it is usually the first building block in 
the theater of operations, airlifted with the initial assault aircraft. The FOSP, on the other 
hand, is usually the last CSP to be deployed. It consists of the heavy machinery and other 
large intermediate-level support equipment. The FOSP is designed to logistically support 


aviation units indefinitely. 


The MALSP, as a whole, is “designed to be mutually supportive and fit together 
like blocks to form a solid aviation support foundation” [1]. The doctrine ensures that 
when contingencies arise, the appropriate level of aviation logistics support is mobilized 
to support the MAGTF ACE. 


3. Information Management Systems 


Marine Corps Aviation Logistics requires the use of numerous Information 
Management Systems to effectively manage the complexity of aviation operations. 
These systems include the Naval Aviation Logistics Command Management Information 
System (NALCOMIS), Shipboard Uniform Automated Data Processing System, Real- 
Time (SUADPS-RT), MAGTF Deployment Support System II (MDSS-ID), Support 
Equipment Resources Management Information System (SERMIS), Local Asset 
Management System (LAMS), and Table of Basic Allowance (TBA). Additionally, the 
Marine Corps Total Force System (MCTFS), a personnel administration system, manages 
all personnel assigned to a unit, which are subsequently tasked to execute aviation 
logistics support operations. Although there is an array of systems currently in use, the 
MALS primarily uses five Information Management Systems, NALCOMIS, LAMS, 
MCTES, TBA and MDSS-II, to input, process, review, report, store technical data and to 


develop deliberate operational plans for aviation support operations. 


NALCOMIS is designed to provide timely and accurate information for day-to- 
day management of aeronautical assets and equipment [1]. The primary capabilities of 
NALCOMIS for the MALS is to requisition material, manage maintenance actions and 
administer to aviation supply assets. NALCOMIS includes 10 subsystems: database 
maintenance, maintenance activity, personnel management, configuration — status 
accounting, asset management, local/up-line reporting, system support, material 
requirement processing, data off-load/on-load and technical publications. NALCOMIS is 
used by both Maintenance and Supply Departments within the MALS. SUADPS-RT, on 
the other hand, is purely an aviation supply application, which consists of three 
subsystems: logistics management, inventory management and financial management. 
Both NALCOMIS and SUADPS-RT systems interface to provide aviation logisticians 
with an efficient capability to accurately manage the myriad of aviation mission-related 


tasks. 


LAMS is a standardized system for management of support equipment at all three 
levels of naval aviation maintenance. LAMS enhances the control of inventory through 
up-line reporting to SERMIS. The system contains the master database of equipment for 


the Aviation Maintenance Material Readiness List (AMMRL) program [1]. 


TBA is a database that provides the initial outfitting allowances for Marine 
Forces. This information system manages the authorized material and organizational 
property for all Marine Corps units. Specifically at the MALS, the TBA provides the 
quantities of mobile facilities the unit is responsible to maintain, but more importantly, it 


establishes the pool of available assets from which MALS can support the MAGTF ACE. 


MDSS-II is the primary Information Management System used for deliberate 
planning of aviation support operations at the tactical level. Unlike NALCOMIS and 
SUADPS-RT, MDSS-II is not an aviation specific application, but a component of a 
larger Marine Corps enterprise system called MAGTF-II. The purpose of MDSS-II is to 
enable planners to develop force structure, tailor force lists, compute sustainment, and 
plan for lift requirements [1]. The product of using the MDSS-II system is the Unit 
Deployment List (UDL), which consists of Time Phased Force Deployment Data 
(TPFDD). The TPFDD is the “who, what, when, and where” of force coordination. 
Once MDSS-II has produced the final UDL, the data is sent to higher headquarters and 
imported into the MAGTF-II system, which manages and produces the TPFDD for the 
entire spectrum of the Marine Air Ground Task Force. 


B. PROBLEMS WITH THE CURRENT SYSTEMS 


The Marine Aviation Logistics community does not possess an application to 
effectively develop operational plans and sustain deployed logistical support forces. 
MDSS-II is a non-aviation specific application that is efficient in documenting and 
reporting operational plans to higher headquarters, but not the IT enabler or decision 
support tool that is needed for developing the key components (personal, parts, support 
equipment and mobile maintenance facilities) of an aviation logistical support plan. The 
problem is further magnified by the fact that each key component of an aviation logistical 
support plan is currently supported by a separate information management system: 


NALCOMIS, LAMS, MCTES and TBA. 


The lack of interoperability of currently fielded systems creates enormous 
challenges for the tactical-level aviation logistics planner and sustainer. Querying 
multiple systems to source a single operation or contingency is laborious, time 
consuming and inefficient. Decision support for sustaining deployed forces is also 
plagued by numerous manual processes, which increases the probability of information 
redundancy, errors, and ineffectiveness. Aviation logistics support is vital to the combat 
readiness of the MAGTF ACE. The current “flat-file” technology used to mitigate the 
lack of system interoperability is not the 21“ century solution for the Marine Aviation 
Logistics community. It is imperative that aviation logistics planners and sustainers at 
the tactical—level have a robust decision support application to accomplish their mission, 
an IT enabler that has the capability to interface with existing fielded systems. 


C. OBJECTIVE 


The objective of this thesis is to develop a web-centric application for Marine 
Aviation Logistics Squadrons (MALS) that can be used to bridge the technology gap 
from the initial stages of developing deliberate, time sensitive and crisis action plans to 
the culmination of the Unit Deployment List (UDL) / Time Phased Force Deployment 
Data (TPFDD) documentation in the MDSS-II system. The intent is to design, 
implement and test a “four-into-one”’ user interface that combines the data sets of existing 
systems to optimize the management, decision support and sustainment of aviation 
logistics operations. The design of the prototype will incorporate the following broad 


system requirements: 
® Concept of Operations (CONOPS) definition 
® Course of Action (COA) definition and comparison 


e Tracking of deployed Personnel, Repair/Spare Parts, Support Equipment 


and Mobile Facilities readiness 
® Tracking of deployed aircraft readiness 
@ Requisition management 


® UDL/ TPFDD Summary 


D. EXPECTED BENEFITS 


A web-enabled application for deliberate, time sensitive and crisis action planning 
at the tactical level will provide numerous benefits over current manual processes. 
Management and decision support for MALS operations would be optimized by 


improving integrity, consistency, flexibility, efficiency, availability and maintainability. 


® Integrity: A web-centric application would provide a centralized point of 
access for internal planning transactions which will eliminate data redundancy during 
planning and sustainment cycles. The system would provide data processes specifically 
tailored for Marine Aviation Logistics and MALSP concepts, and save valuable man- 


hours correcting and/or updating source documents. 


e Consistency: A web-enabled application would provide an intuitive user 
interface and a reliable format for both internal and external planning and sustainment 
coordination efforts. Employing a standard web browser as the database interface would 


minimize the training required for personnel to use the application. 


© Flexibility: A web-centric system would be conducive for collaborative 
planning and execution at work, planning conferences, or at remote sites—anywhere 
internet access is available. The application would also take advantage of existing and 
emerging wireless technologies: PDA, Pocket PC, cell phone, and other equipment that 


have integrated web browsers. 


@ Efficiency: A real-time web-centric system would improve the planning 
and decision-making time cycles by reducing the number of deployment meetings and the 
use of “flat-file’ information technology. A system of this nature would improve 
visibility and response times for deployment material support requests and subsequent 
action of material requirements. The system would also improve data analysis by quickly 
searching the database for historical and current deployment data to identify trends and 


other relevant information. 


® Availability: A web-enabled application would provide reliable, near real- 


time information on aircraft, personnel and maintenance/supply support requirements for 


deployed forces. A system of this nature would provide globally visible information and 


take advantage of widely available internet access. 


® Maintainability: MALS (AISD) currently has the Information 
Technology architecture to employ and maintain a system of this nature; no additional 
personnel or hardware requirements would be required. The benefit of a web-enabled 
application is that the MALS deployment and garrison Information Technology footprint 
would remain the same. 


E. METHODOLOGY 


The analysis of capabilities and constraints of MALSP doctrine and the existing 
Information Management Systems used to execute mission requirements was 
accomplished by a literature review and by formal surveys of current MALS Operations 
Officers, an authoritative source and lead planners for all aviation logistics support 
operations at the tactical level. Aviation Maintenance and Supply Officers were also 
surveyed due to their vital role in the execution and sustainment phases of aviation 


support operations. 


The system design methodology for developing the web-enabled database was 
Rapid Action Development (RAD), a prototyping methodology. Operations Officers 
from both MALS-36 and MALS-11 were active end-user in this thesis research. They 
provided the necessary feedback for the prototype iteration process. The web-enabled 
prototype was hosted on a Naval Postgraduate School (NPS) server (ebiz.nps.navy.mil), 


which provided the ideal environment towards a proof of concept for this research. 


The Database and Web Technologies Lab, located at NPS, was used to test and 
analyze web interface usability features and system functionality by performing a 
usability experiment. There were many students assigned to NPS who had Marine 
Aviation Logistics backgrounds, including Aviation Supply, Aviation Maintenance, and 
former MALS Operations Officers. Using personnel familiar with aviation logistics 
processes and procedures in a lab environment was beneficial in identifying and 
confirming user requirements and streamlining usability features and prototype processes 
to ultimately produce to an efficient and effective application to plan and execute aviation 


logistics support operations. 


F. ORGANIZATION OF THE THESIS 


The remaining chapters of this thesis are organized as follows: Chapter II 
analyzes the strengths and weaknesses of MALSP doctrine and the current initiatives that 
will transform aviation logistics to meet 21st century requirements. An analysis of the 
existing Information Management Systems used for operational planning and sustainment 
is accomplished in Chapter III. Chapter IV is focused on data and logical process 
modeling for the development of the web-enabled prototype. The development and 
deployment of the prototype is discussed in Chapter V. Web interface usability features 
tested in the Database and Web Technologies Lab are summarized in Chapter VI. Lastly, 


Chapter VIII discusses lessons learned, conclusions, and directions for future research. 
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Il. ANALYSIS OF MALSP DOCTRINE 


This chapter analyzes the strengths and weaknesses of MALSP doctrine and the 


current initiatives that will transform aviation logistics to meet 21“ century requirements. 


The chapter is organized as follows. Section A describes why MALSP was 
originally implemented; Section B discusses the successes of MALSP since its inception; 
Section C analyzes the historical shortcomings of MALSP doctrine and its relevancy to 
today’s strategic environment; and Section D discusses the transformation strategy for 
Marine Aviation Logistics to respond to the unpredictable challenges of 2015 and 
beyond. 

A. MALSP DOCTRINE 


Prior to 1988, Marine Aviation Logistics (AVLOG) support for the MAGTF ACE 
was an ad hoc process at best. Headquarters and Maintenance Squadrons (H&MS) relied 
upon the resident expertise of maintenance and supply personnel to determine the optimal 
composition of personnel, parts, support equipment, and mobile facilities to support a 
deployment or contingency [2]. Because of varying degrees of experience within H&MS 
across the Marine Corps, an inconsistent concept of operations for logistics support was a 
common result; both shortfalls and excess capabilities often coexisted for task-organized 
contingencies, which ultimately led to reduced combat readiness. These systemic issues 


were addressed with the introduction of MALS and MALSP doctrine. 


MALS and MALSP doctrine was officially implemented in October 1988 [3]. 
This transformation included the structural reorganization of H&MS into MALS, which 
consolidated the responsibility of AVLOG support at the tactical level to one squadron. 
However, it was MALSP that was the key piece of the transformation process. The 
introduction of new doctrine led to the ability to rapidly task-organize and execute 
aviation logistics support operations for major theater-level war [4]. 


B. MALSP SUCCESSES 


For nearly 20 years, MALSP doctrine has served the aviation community 
sufficiently. The following is summary of operations where MALSP doctrine has been 


used (and continues to be used today) to support MAGTF ACE missions: 
1] 


Desert Shield Desert Storm Fiery Vigil 
(Kuwait) (Kuwait) (Philippines) 


Provide Comfort Victor Squared Southern Watch 
(Turkey) (Haiti) (Iraq) 


Restore Hope Provide Promise Deny Flight 


(Somalia) (Yugoslavia) (Bosnia) 


Continue Hope Eyes of Mogadishu Quick Draw 


(Somalia) (Somalia) (Somalia) 


Uphold Democracy | Decisive Endeavor | Assured Response 


(Haiti) (Bosnia) (Liberia) 


Deliberate Guard Silver Wake Deliberate Forge 
(Bosnia) (Albania) (Bosnia) 


Allied Force Noble Anvil Avid Response 
(Kosovo) (Kosovo) (Turkey) 


Allied Harbor Joint Guardian Stabilize 
(Albania) (Kosovo) (East Timor) 


Enduring Freedom Secure Tomorrow Iraqi Freedom 


(Afghanistan) (Haiti) (Iraq) 





Table 1. MALSP Employment Since 1988 


The implementation of MALSP dramatically improved AVLOG support from an 
improvised, makeshift process to a standardized, predetermined contingency support 
package concept that is capable of supporting the multitude of missions Marine Corps 
Aviation may be tasked to execute [1]. Although the “building block” doctrine has 
successfully supported combat sorties, humanitarian missions, enforcing no-fly zones and 
other MAGTF operations, Table 1 above also reveals a trend. With the exception of 
Operations Desert Storm and Iraqi Freedom, 21“ century contingencies are of a smaller 
scale and not the major theater-level engagements that MALSP was originally designed 


to support. 
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U. MALSP SHORTCOMINGS 


MALSP was developed in the Cold War era, where major theater engagements 
were the strategic focus. The Cold War has now ended, but the doctrine used to support 
the MAGTF ACE has not [5]. Since MALSP has been implemented, major theater 
engagements account for just 7% of MALSP utilization whereas 93% can be considered 


smaller scale contingencies. 


Looking through the macro-level lens, the underpinnings of MALSP doctrine are 
no longer an efficient option for today’s strategic environment. The proliferation of 
weapons of mass destruction, terrorism, and the global economy are all drivers of a new 
strategic landscape. Furthermore, nations are less likely to engage the United States in 
conventional, major theater-level, operations due to its overwhelming military strength 
and technological advantages. Smaller scale contingencies have become the norm not the 
exception; therefore, a doctrinal shift is, once again, required for Marine Aviation 
Logistics to respond to the full spectrum of events that threaten global stability and 


national interests. 


The shortcomings of MALSP doctrine are also demonstrated at the micro-level. 
In 1999, MALS-31, located in Beaufort, South Carolina, was tasked to support the 
NATO action of stopping Serbian military aggression against ethnic Albanians in 
Kosovo, with the intent of restoring Kosovo’s borders and promoting regional stability. 
The mission, Operation Noble Anvil, required MALS-31 to deploy a tailored yet self- 
sustaining support package for 24 F/A-18D aircraft. Although the task seemed well 
suited to utilize MALSP, logistics planners had significant hurdles to clear in order to 


effectively support the operation. 


Operation Noble Anvil posed significant problems for logistics planners because 
support from MPF and TAV-B ships were not planned to be used for this deployment [2]. 
This challenged the fundamental assumption of MALSP doctrine that calls for 
contingency support packages to be integrated with the capabilities of MPF and T-AVB 
ships; the former to provide essential pre-positioned support equipment and ordnance, 


and the latter a means of rapid and dedicated sealift into an area of operations. 
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With these key components unavailable, MALS-31 had no choice but to deviate 
from doctrine. As a result, they developed and deployed a Remote Expeditionary 
Support Package (RESP): a stand-alone support capability consisting of people, parts, 
Support equipment and mobile facilities that can sustain operational requirements 
independently [5]. Despite the challenges, MALS-31 was successful in maintaining an 
aircraft mission capability rate of 92% [2]. The development and implementation of the 
RESP was successful, gained acceptance, and was formally integrated within MALSP 
doctrine by the publication of Aviation Logistics, Marine Corps Warfighting Publication 
3-21.2, in October 2002. Nonetheless, Operation Noble Anvil is an example where 
MALSP had to be revised due to its inefficiency of supporting smaller-scale 


contingencies. 


Another problem with MALSP doctrine that is rooted from a decades-old 
mentality is the concept of having standardized and predetermined support packages. 
The foundational “building blocks” of MALSP, the Peculiar Contingency Support 
Package (PCSP) and Common Contingency Support Package (CCSP), supports the 


deployment and logistics requirements of entire squadrons or groups of squadrons during 





a major theater war [5]. For example, an F-18 PCSP is built to support 36 aircraft, which 
is equivalent to three squadrons. Theoretically, if all 36 aircraft deploy, then MALSP 
works as intended. However, if only two squadrons deploy, e.g., Operation Noble Anvil, 
with a “standardized and predetermined” PCSP, then 24 aircraft undoubtedly have a 
robust logistics support package, but consequently the 12 F/A-18 aircraft that remain 
behind in garrison have lost a significant amount of supporting personnel, parts, support 
equipment and mobile maintenance facilities. All of which significantly reduce the 
ability of those 12 F/A-18 aircraft to continue to “train as they would fight” and remain 
combat ready in case they are needed. Hence, MALSP is not inherently flexible or 
sufficient to support smaller-scale contingencies in its current state. In light of the 
increasing number and variability of smaller-scale contingencies in the 21“ century, the 
Marine Corps must re-focus it aviation logistics support concepts from “standard-sized” 


packages to “‘right-sized” packages [5]. 
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D. TRANSFORMATION OF MARINE AVIATION LOGISTICS 


The shortcomings of current MALSP doctrine are well documented; Marine 
Aviation Logistics must respond more efficiently to the ever-increasing and unpredictable 
missions of the 21“ century [6]. The current transformation strategy that will enable 
effective AVLOG support in the future consists of three concepts: AirSpeed, MALSP-II, 
and MALS-Future. These concepts are an integrated and multi-year undertaking that will 
culminate with the implementation of MALS-Future, a responsive and light-weight 
logistical support activity that is capable of sustaining the MAGTF ACE’s warfighting 
requirements of 2015 and beyond. MALS-Future is currently under research by the 
Marine Corps Studies System with the intent of proposing a new business model and 
structure for the future of MALS squadrons [7]. 

At the core of the cultural shift is the United States Navy’s new logistical 
enterprise philosophy of AirSpeed. This new philosophy is a blend of proven business 
tools including Theory of Constraints (TOC), Lean and Six Sigma [5]. The purpose of 
AirSpeed is to optimize the performance of logistics practices and decision-making at all 
levels of the logistics chain by focusing on interdependencies, constraints and variability 
of current practices. The end result is a new methodology of managing assets and a 
streamlined logistical support system. 

The AirSpeed philosophy is currently being implemented on a limited basis and 
has already received some positive feedback. MALS-26, located at New River, North 
Carolina, was the first MALS squadron to put theory into action in 2004. Using the 
components of AirSpeed, MALS-26 noticed process improvements and increases in 
efficiency with their maintenance and diagnostic workbenches [8]. “Theory of 
Constraints (TOC) and the focus on Lean is helping to achieve our goal...AirSpeed 
improvement tools help to maintain and sustain our readiness,” said the Executive Officer 
from MALS-26 [8]. 

The next step in the transformation process 1s MALSP-II, a new aviation logistics 
doctrine that addresses the challenges of supporting both small-scale contingencies 
abroad and remain-behind elements at home. Agility, flexibility, responsiveness, 
adaptability, sustainability, and proactiveness are the benchmark requirements for success 
[5S]. The goal is to move away from the enormous logistical infrastructure of a forward- 
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deployed MALS under current MALSP doctrine. Area denial and anti-access in foreign 
regions, Expeditionary Maneuver Warfare (EMW) and sea-basing are all factors that 
require a lighter more agile logistics footprint. 

To accomplish these goals, MALSP-II will leverage AirSpeed concepts and 
incorporate emerging technologies. An essential concept of AirSpeed that is applied to 
MALSP-II is a system “buffers.” The purpose of the buffer system is to increase the 


effectiveness of logistical support while reducing infrastructure and resources [5]. 
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Figure 4. MALSP-II Concept of Buffers [From: 5] 


Figure 4 above depicts the intended transformation from MALSP to MALSP-II 
and how the system of buffers is utilized to shift from “pushing” a large “standardized” 
infrastructure into a crisis region to a series of “right-sized” logistical support centers 
capable of “pulling” resources from a geographically dispersed supply chain. Buffers are 
identified and managed by a stop-light model, where green represents sufficient resources 
on-hand; yellow means resources have been used and replenishment plans should be 
initiated; and red means action is now needed for current and future operations. 
Individual buffer levels are determined by the pattern of demand and the time to rapidly 


replenish (TRR) the resource. 


Current MALSP doctrine is constrained by Cold-War assumptions that are no 
longer relevant. MALSP-II is an effective transformation strategy to manage logistics 


assets and reduce the footprint required for smaller-scale contingencies expected in the 
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21" century. However, agility, flexibility, responsiveness, adaptability, sustainability, 
and proactiveness can only be fully realized by effectively leveraging Information 
Technology (IT). Clearly, the visibility and timely flow of information is critical to the 
success of MALSP-II. Concept of Operations (CONOPS) planning and managing 
multiple buffer nodes, consisting of personnel, parts, support equipment, and mobile 


facilities, requires a robust IT enabler. 


This chapter analyzed the strengths and weaknesses of MALSP doctrine and the 
current transformation initiatives being pursued for naval aviation. Implicit in all past, 
present, and future aviation logistics actions 1s the vital role of information management 


systems, which will be discussed in Chapter III. 
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Hl. ANALYSIS OF THE INFORMATION MANAGEMENT 
SYSTEM 


This chapter analyzes the strengths and weaknesses of the MAGTF Deployment 
Support System II (MDSS-II), and quantifies the extent of the current decision support 


problem by analyzing formal surveys distributed to aviation logistics professionals. 


The chapter is organized as follows. Section A describes the MDSS-II system 
and how it is integrated within the LOGAIS family of systems; Section B analyzes the 
shortcoming of MDSS-II for the aviation logistics community with regard to developing 
logistical support plans; Section C is a concise statement of the problem from which this 
thesis 1s conceived; and Section D discusses the quantifiable evidence of the need for a 
robust decision support tool for aviation logistics planners and sustainers. 


A. MDSS-II 


The MAGTF Deployment Support System II (MDSS-II) is the primary 
Information Management System used for deliberate planning of aviation logistics 
Support operations at the tactical level. MDSS-II is a component of a larger Marine 
Corps enterprise system called MAGTF-II. MAGTF-II interfaces with the Global 
Command and Control System (GCCS) and the Joint Operation Planning and Execution 
System (JOPES), the central Information Management System where U.S. military inter- 
service operational plans (OPLANS) and operations orders (OPORDS) are published. 
JOPES is an effective system for providing the Joint Chiefs of Staff (JCS), Combatant 
Commanders and the U.S. Transportation Command with the information needed to 
manage and support deployed forces [1]. The following diagram depicts the Information 
Management Systems used for Force Deployment Planning and Execution (FDP&E) 


from the macro-perspective: 
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Figure 5. Information Management System Relationships 


The purpose of MDSS-II is to enable tactical-level planners to develop force 
structure, tailor force lists, compute sustainment and plan for lift requirements [1]. The 
product of the MDSS-II system is the Unit Deployment List (UDL), which is unit 
specific Time Phased Force Deployment Data (TPFDD) for an operation. The TPFDD 
identifies capabilities; it is the “who, what, when, and where” of force coordination. One 
the UDL consolidated and reviewed at the squadron level is sent to higher headquarters 
and imported into the MAGTF-II system, which manages and produces the TPFDD for 
the entire spectrum of the MAGTF. 

B. DOCUMENTING VS. DEVELOPING LOGISTICAL SUPPORT 


From the micro-perspective, MDSS-II is an effective information management 
system for documenting capabilities—personnel, aircraft parts, support equipment, and 
mobile facilities—for a contingency or deployment, but not an efficient system for 
identifying or developing those capabilities. MALS squadrons do not have an effective 
decision support system for identifying, developing and consolidating CONOPS 
information for aviation logistical support. At the present time, MALS planners are 
required to query and consolidate data from multiple information management systems, 
each specifically designed to manage a single component of the logistics support package 


concept—personnel, aircraft spare/repair parts, support equipment, or mobile 
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maintenance facilities. Moreover, deliberate, time sensitive and crisis action planning for 
contingencies, exercises and other CONOPS, where no previous support data exists, must 
be initiated from scratch—a significant challenge when time limited and mission critical. 
As a result, the MALS Operations (S-3) and Logistics (S-4) Departments are forced to 
expend resources and valuable man-hours manually developing and documenting the 
aviation logistics CONOPS due to the lack of integrated information management 
systems. The following figure depicts the current architecture of information 
management systems used to develop and document aviation logistics support for an 


operation or contingency. 
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Figure 6. Developing Versus Documenting OPLANS 


C. PROBLEM STATEMENT 


No effective Information Management System exists for developing deliberate, 
time sensitive, or crisis action plans for tactical-level aviation logistics support operations 


that is integrated with the LOGAIS family of systems (MDSS-II/MAGTF-II/JOPES). 
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D. QUANTIFYING THE PROBLEM 


1. 


To capture and quantify the extent of the problem, surveys were distributed to 
personnel currently operating at MALS units throughout the Marine Corps. There were 
eight respondents of the survey, which included MALS Operations Officers, Aviation 
Maintenance Officers, and Aviation Supply Officers. All respondents have experiences 
in planning and executing aviation logistics support operations from Operation Desert 


Storm to the current and ongoing Operation Iraqi Freedom and the Global War on 


Data Collection 


Terrorism. The following is the data collected from the formal survey: 


Figure 7. 


Figure 8. 








What software application is normally used by the Operations Department for 
delibrate, time sensitive, and crisis action planning? (Select all that apply) 
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Survey Results: Software Used for AVLOG Planning 





What is the most significant software application used by the Operations 
Department to conduct delibrate, time sensitive, or crisis action planning? 














GB MS Excel 

@ MS Outlook 
O MS Word 
O MDSS II 

@ MS Access 
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Survey Results: Most Significant Software Used for AVLOG Planning 
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Collaborative planning for exercises, deployments or contingencies are normally 
accomplished by what means? (Select all that apply) 
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Figure 9. Survey Results: Methods of Collaborative Planning 





Ona scale of | to 5 (1 = Not Useful, 5 = Very Useful), how would you rate 
the MDSS-II application for delibrate, time sensitive, or crisis action planning? 
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Figure 10. Survey Results: Rating of MDSS-II for Planning 





Historical records of exercises, deployments, contingencies are maintained 
by what means? (Select all that apply) 
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Figure 11. Survey Results: Methods of Maintaining Historical Records 
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Exercise, deployment, and contingency material support requests for MALS are 
normally received by what means? (Select all that apply) 
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Figure 12. Survey Results: Means of Receiving Material Support Requests 


Figure 13. 





What is the most significant communication method currently used to receive and 
act upon material support requests from exercises, deployments, or 
contingencies? 
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Survey Results: Most Significant Methods of Material Support Requests 





Exercise or deployment reporting (aircraft, requisitions, personnel and 
equipment status) is normally accomplished by what means? 
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Figure 14. Survey Results: Means of Deployment Reporting 
24 





What is the most significant communication method currently used to receive 
aircraft, requisition, personnel, and equipment status? 
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Figure 15. Survey Results: Most Significant Means of Deployment Reporting 





During an exercise or deployment, how often (average) is the Operations 
Department updated on aircraft, requisitions, personnel and equipment status? 
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Figure 16. Survey Results: Frequency of Deployment Reporting 





Based on your experience with current processes and procedures of Aviation 
Logistics, you would____that a real-time, web-enabled application may be 
beneficial for collaborative planning of deployed tactical-level (MALS) aviation 
logistics forces. 
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Figure 17. Survey Results: Web-Enabled Application for AVLOG Planning 
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The MDSS-II application is not the robust Information Technology (IT) enabler 
needed for planning aviation logistics support operations, only 37% of the respondents 
cited MDSS-II as the application that is normally used by the Operations Department for 
deliberate, time sensitive, and crisis action planning. However, 100% of the respondents 
cited the “flat-file” technologies of Microsoft Excel and Microsoft Word as the normal 
applications used to execute planning requirements. MDSS-II did not fair well as a 
collaborative planning tool either: Microsoft Excel (75%), Microsoft Word (75%), and 
Microsoft Outlook (75%) all outpaced MDSS-II (62%) as the tool most commonly used 
to accomplish internal and external collaborative planning functions. The most 
significant finding from the formal survey; however, is that 67% of respondents rate the 
MDSS-II application as a one (1) on a sliding scale of one to five (1 to 5), with one (1) 
equaling “not useful” and five (5) equaling “very useful.” From the survey, it is clear that 
MALS could benefit from the inherent value and collaborative nature of a web-enabled 


decision support tool. 


The survey of aviation logistics professionals also revealed some current 
inefficiency related to sustaining deployed forces. First, Microsoft Excel (via Microsoft 
Outlook) is the most significant application for receiving aircraft, requisition, personnel, 
and equipment status updates from deployed forces. Second, Microsoft Excel is by far 
(75% of all requests) the most common means of receiving deployment or contingency 
material support requests from deployed forces. Third, Microsoft Excel is second only to 
the official Aircraft Material Readiness Report (AMRR) as the means of deployment 
reporting, with the former published just once a day. Although aviation logistics planners 
and sustainers have an array of available software applications, none is more vital to their 
mission than Microsoft Excel; 75% of the respondents cited the application as the “most 


significant” software application used for planning and sustaining purposes. 


Hence, MALS Operations Departments are using Microsoft Excel to mitigate the 
shortfalls of currently fielded systems and the lack of system integration. Although 
Microsoft Excel is a very popular application with useful functionality, the problem with 


using spreadsheets as a planning tool is that they are inherently designed for personal, not 
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collaborative, productivity. Sharing of Microsoft Excel files requires the use of email or 
a shared network drive, which then leads to the problem of document-version control 
(data integrity) as more users participate in the planning process. As a result, scarce man- 
hours are expended updating the source document for already time sensitive task. 
Furthermore, pseudo-centralization of a spreadsheet on shared network drive is not 
sufficient since only one user at a time can modify the document. Multi-user access is a 
requirement for efficient coordination with Maintenance, Supply, AISD and the Logistics 


Departments. 


Information redundancy and inconsistent format is another problematic issue; 
over time, planning multiple exercises or contingencies results in multiple spreadsheets 
with no guarantee of a consistent format within (internal planning) MALS, let alone 


coordination that may be required with another MALS (external planning). 


The use of “flat-file’ technology is not the most conducive means _ for 
collaborative planning or sustaining deployed forces. The decentralized nature of 
spreadsheets does not provide the functionality to effectively manage the information 
requirements of aviation logistics planning and sustainment operations. The complexity 
of planning and coordination required to properly execute current and future MALSP 
doctrine would be better served by implementing an information management system 


specifically designed for aviation logistics support operations. 


The requirement for such a system was validated in June 2005 at Marine Aviation 
Maritime Pre-Positioning Force (MPF) Pre-Tailoring Conference. At the conference, 
attended by key Marine Aviation logistics planners from throughout the Marine Corps, 
the future aviation logistics requirements workgroup identified the need for a robust 
decision-support tool for aviation logistics planning. The following is a summary of the 


discussion and recommendations [9]: 
e AVLOG Planners lack integrated planning tools. 


® The lack of an AVLOG plans-specific decision support tool does not 
allow for detailed planning and integration with the MAGTF-H/LOGAIS family of 


systems. 


Da 


e MDSS-II data is currently entered by hand. 


® Deployments are seldom based upon a notional MAGTF. Each 
deployment requires new embarkation data package, but planners lack the tools to 


quickly create new packages. 


e MALS needs a decision support tool that helps to source MDSS-II by 


extracting supply, maintenance, and IMRL data to tailor support packages. 


Hence, the goal of this thesis is to develop a web-enabled prototype that 
implements the support concepts of MALSP-II and optimizes CONOPS planning and 
management capabilities that have been identified in the survey and validated by the 
aviation logistics planners’ discussion of future requirements. The MALS would 
certainly gain from a web-enabled database, as evidenced by 75% “strongly agreeing” 
and 25% “agreeing” that a web-enabled application may be beneficial for collaborative 


planning and sustainment of deployed tactical-level aviation logistics forces. 


This chapter identified and quantified the problem with developing aviation 
logistical support plans using the current information management systems. The analysis 
clearly established a need for a robust application for the MALS. The development for 


such an application is discussed in Chapter IV. 
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IV. ANALYSIS AND DESIGN OF PROTOTYPE APPLICATION 


This chapter discusses the methodology and tools used to develop the MAPSS 
prototype. This chapter then presents the conceptual data and logical process models 


used to design the web-enabled application. 


The chapter is organized as follows. Section A describes Rapid Application 
Development (RAD) and why this methodology was appropriate for an aviation logistics 
planning and sustainment application; Section B discusses the software development 
tools used for building the prototype; Section C discusses the mechanics of generic 
conceptual data modeling and then illustrates three specific data models that were 
developed for the MAPSS application; and Section D discusses the importance of logical 
process modeling, and then illustrates the information and control flow diagrams for the 
three system processes. 


A. PROTOTYPE METHODOLOGY 


The methodology used to develop the Marine Aviation Planning and Sustainment 
System (MAPSS) was Rapid Application Development (RAD), a strategy that 
emphasizes speed and user involvement in the iterative development of software 
prototypes [10]. The RAD methodology was developed by Jamie Martin in 1991, which 
is essentially a descendent of the Spiral Development Model developed by Barry Boehm 
in 1986, which emphasized prototyping as an effective means of developing software 
[11]. RAD is an evolutionary process: develop, test, refine system requirements, and 
then repeat the process. Prototypes are continuously developed until users are satisfied 
that system requirements have been successfully discovered and implemented into a 
working system. 

RAD is an appropriate methodology for developing an application for Marine 
Aviation Logistics Squadrons (MALS). As discussed in Chapter II, Marine Aviation 
Logistics is currently undergoing a transformation from MALSP doctrine to MALSP-II. 
As a result of the ongoing transformation, some system requirements for an operational 
planning and sustainment system are currently unknown and some known requirements 


will inevitably change as the multiyear transformation progresses. 


29 


In light of current state of the aviation logistics community, traditional software 
development strategies may be inappropriate, ineffective and undoubtedly expensive. 
RAD, on the other hand, is methodology that enables an application—an IT enabler—to 
be developed in parallel with the current transformation. The iterative approach to 
prototyping allows known requirements to be developed and tested and new or 
unforeseen requirements to be included with future implementations or spirals of the 
prototype. A decision support prototype application for aviation logistics is a win-win 
situation for MALS; it addresses current information technology needs and it is flexible 
enough to incorporate MALSP-II and MALS-Future concepts as they are developed. 

B. DEVELOPMENT TOOLS 


Three tools were used to develop the MAPSS prototype: Microsoft Access 2003, 
Microsoft Visio 2003, and Macromedia Dreamweaver MX 2004. Microsoft Access is a 
powerful yet user-friendly program for creating and managing relational databases that is 
used by both home users to create personal applications and professional software 
developers to create enterprise-wide applications. For the purposes of this thesis, 
Microsoft Access was used to create the back-end relational database for the prototype. 

Microsoft Visio 2003 is a computer-aided software engineering (CASE) tool. 
CASE tools are an essential element in any information systems development process; 
they allow developers to quickly and accurately draw modeling diagrams, create 
prototype user interfaces, perform system specification analysis, and even generate 
executable code [12]. Microsoft Visio 2003 was used to create the conceptual data 
models and logical process models for the MAPSS prototype. 

Macromedia Dreamweaver MX 2004 is a professional web development program. 
This tool allows both beginners and advanced web-designers to create professional web 
pages quickly and easily. The advantage Macromedia Dreamweaver has over other web 
development products is its user-friendly integration of advanced web development 
technologies and functionalities[13]. Dreamweaver allows beginners to design pages 
using the WYSIWYG interface or advanced users to design directly from code. The 
intuitiveness for the beginner yet the robust capability for advanced web designers are a 
rare combination in software. Dreamwever MX 2004 was used to create the web-based 
front end, the user interface, of the MAPSS prototype. 
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C. CONCEPTUAL DATA MODELS 


Data modeling is an efficient way to document how data is organized and stored 
in a relational database [10]. There are many different types of data models used by 
developers to design and analyze data to be stored for an organization, each with its own 
specific notation and benefits. The type of data model used and level of detail is a 
product of design methodology, time available to deliver the application, and the 
developer’s preference. One thing is certain, however; data models should always be part 
of the development process. 

The Entity Relationship Diagram (ERD) was the type of data model used to 
develop the MAPSS prototype. ERD is a popular methodology for conceptual data 
models; it is a method that utilizes several notations to depict data in terms of entities and 
relationships [10]. Given that the RAD methodology calls for speed and quick 
development of prototypes, the level of detail and analysis for the MAPSS prototype was 
intentionally compressed and abbreviated. Conceptual data models for the MAPSS 
prototype were developed in three steps: (1) context data model, (2) key-based data 
model, and (3) fully attributed data model. 

1. Context Data Model 


The context data model was the first step of the MAPSS conceptual data 
modeling effort. The purpose was to identify the high-level entities and relationships for 
the MAPSS database. An “entity” is defined as persons, places, events, or concepts about 
which an organization chooses to record data [12]. A “relationship” is a natural business 
association between one or more entities [10]. For example, MALS, a SQUADRON is 
an entity, and OPERATION, an event, is also an entity, and both are elements of data that 
must be maintained in the database. Since SQUADRONS are tasked to execute 
OPERATIONS, there is a natural business or doctrinal “relationship” between these 


entities. In short, entities are usually nouns and relationships are usually verbs. 


Before a context data model can be developed; however, an organization must be 
examined. A discovery process is needed to capture the relevant entities and 
relationships for the system. This examination of the organization can accomplished in 


numerous ways, such as interviews with intended users, observation of the organization, 
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surveys and questionnaires, review of doctrine or applicable laws, or an assessment of 
current system capabilities, to name just a few discovery methods. Since MAPSS was 
designed as a decision support tool for operational planning and sustainment, the 
discovery process was focused on the MALS Operations Department (S-3) and their 
functional requirements of developing Concepts of Operation (CONOPS), Courses of 
Action (COA), and sustaining deployed forces. Surveys, interviews with intended users, 


and a review of doctrine were the discovery methods for this thesis research. 


CONOPS development was one of the central requirements for the system. The 
key entities identified were operation, squadron, aircraft, and course of action. These 
entities are related in that operations are normally supported by squadrons, aircraft, and 
should have multiple courses of action planned to execute the operation. In addition to 
the above requirements, a logbook and a 782-gear list are two entities that should be 
maintained (albeit not essential) for an operation. There are benefits to documenting 
chronological events, as well as maintaining a list of items that personnel are required to 


deploy with. 


Course of Action (COA) development was another primary consideration for the 
prototype. In fact, COA development is mandated by the Marine Corps Planning Process 
(MCPP). Developing a COA for aviation logistics support requires planners to consider 
multiple variables. According to aviation logistics doctrine, a COA normally consist of 
personnel, repair parts, support equipment and mobile maintenance facilities. As 
mentioned in Chapter I, these entities are the basic “building blocks” for aviation logistics 


support. Hence, COA development is centered on the assignment of these entities. 


COA development also has natural relationships to other concepts, places and 
events, such as tasks, locations, vehicles, and host nation support. Tasks are the (what) 
actions that need to accomplished prior and during COA selection and execution. 
Deployment locations (where) and vehicles (how) are key entities that should be 
maintained and used to differentiate and facilitate COA selection. Moreover, host nation 


support is an essential concept that must accounted for; it determines the services and 
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other support that will be provided to deployed forces, which reduces the logistical 
footprint, saves resources, and aids planners in tailoring support packages that will meet 


mission objectives. 


The last area of discovery for the decision support system was operational 
sustainment. This requirement primarily involves the situational awareness and reporting 
requirements of the previously mentioned entities: operation, aircraft, squadron, 
personnel, repair parts, support equipment, and mobile facilities. Situational awareness 
and near real-time operational visibility are key ingredients to effective leadership and 


timely decisions. 


Requisition management was also considered a vital concept to operational 
sustainment. The mission of the MALS is to maintain the combat readiness of the 
MAGTFE ACE, and readiness is maintained by providing aircraft with the repair parts and 
maintenance actions they need to continue flying combat missions. Hence, an effective 
decision support tool must include the ability to initiate, update, complete, and track 


requisitions for aeronautical equipment. 


The discovery process provided the means to identity the high-level entities and 
relationships that were used to start the MAPSS database development cycle. The 
following figure depicts the context data model for the MAPSS prototype that provided 
the base from which the key-based and fully attributed data models were developed. 
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Figure 18. Context Data Model 
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Z. Key-based Data Model 


The key-based data model was the second step in the database design process. 
The purpose of this step was to further develop entities and relationships by documenting 
cardinality, an important step in the physical representation of the database. The term 
“cardinality” is defined as the minimum and maximum number of occurrences of one 
entity that may be related to a single occurrence of the other entity [10]. The following 


figure illustrates the most common cardinality notation and its interpretation. 


CARDINALITY MINIMUM MAXIMUM GRAPHIC 
INTERPRETATION NOTATION 


Exactly one 7] 
(one and only one) 
po 


Zero, one, or more many (>1) 
_ 


Figure 19. Information Engineering Cardinality Notation [From: 10] 


— 2 





Primary keys and foreign keys are important concepts to understand and essential 
to proper implementation of a relational database. A “primary key” is an attribute or a 
group of attributes that assumes a unique value for each entity instance [10]. A “foreign 
key” is a primary key of an entity that is used in another entity to identify instances of a 
relationship [12]. An example is the most effective way to demonstrate primary and 


foreign key concepts. 
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Squadron Aircraft 


x au 





Figure 20. Primary and Foreign Key Example 


HMM-265, located in Okinawa, Japan would be single instance of the 
SQUADRON entity. The primary key (PK) for the SQUADRON entity (data relating to 
the single instance of HMM-265) could be the Unit Identification Code (UIC). The UIC 
is a good candidate for a primary key because it uniquely identifies HMM-265 from all 
other squadrons in the Marine Corps and the value will never change. Moreover, a single 
CH-46E helicopter would be an instance of the AIRCRAFT entity. The primary key for 
the AIRCRAFT entity (data relating to the single instance of a helicopter) could be the 
Bureau Number (BUNO). The BUNO is a good candidate for a primary key because it 
uniquely identifies a specific aircraft and the value is permanently assigned and will not 
change. From Figure 20, UIC is also a foreign key (FK) for the AIRCRAFT entity, 
which indicates a business rule or relationship. Hence, the graphical notation above is 
interpreted as a SQUADRON may (optional) have one-to-many AIRCRAFT assigned 
and an AIRCRAFT must be assigned (required) to only one SQUADRON. Key-based 


models are a quick and an efficient tool for developing relational databases. 


There is one more aspect of key-based models that needs to be discussed: many- 
to-many relationships. When designing relational databases, many-to-many relationships 
must be treated differently than other relationships. Developers using Microsoft Access 
2003 cannot directly define many-to-many relationships; therefore, they must add a join 
or junction entity and relate the two entities using two one-to-many relationships [14]. 


The following figure demonstrates the concept. 


Squadron 





Sqdn_ID ID 


Figure 21. Many-to Many Relationship Example 
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Although the “real-world” relationship is one where a SQUADRON may be 
tasked to execute many OPERATIONS, and an OPERATION may be executed by many 
SQUADRONS, the logical relationship for a relational database requires the introduction 
of the JoinSqdnOp entity with two one-to many relationships and the foreign keys from 
the SQUADRON and OPERATION entities. The following figure is the key-based data 
model for the entire MAPSS prototype. 
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Figure 22. Key-based Data Model 
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3; Fully Attributed Data Model 


The last step in the MAPSS conceptual data modeling process was the fully 
attributed data model. In addition to documenting all attributes for the entities, 
normalization was performed. The term “attribute” is defined as a descriptive property or 
characteristic of an entity [10]. For example, last name, first name, height, weight, blood 
type, etc., are attributes for the entity PERSONNEL. “Normalization” is defined as a 
data analysis technique that organizes data into groups to form non-redundant, stable, 


flexible, and adaptive entities [10]. The following figure depicts the fully attributed and 
normalized data model for the MAPSS prototype. 
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Fully Attribute Data Model 
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D. PROCESS MODELS 


Process models differ from data models. Although the purpose of both is to 
represent a view of reality, a process model has the distinction of describing the system 
processes, whereas a data model represents the data needed by these processes. Process 
models are graphical representations of what the application was designed to accomplish. 
Process models are independent of data models in that process models depict what the 
user of the system will see and/or execute, while data models are usually transparent to 
intended users and used solely by developers to design and accurately develop the back- 


end of the system—the relational database. 
1. System Requirements 


Process models should be directly related to systems requirements. Since process 
models describe what the system will do, developers must design the application’s 
processes with system requirements in mind. As discussed in Chapter I of this thesis, the 
intent of the MAPSS prototype is to be a robust application for AVLOG planners, 
enabling them to develop deliberate, time sensitive and crisis action plans and sustain 
tactical-level aviation logistics support operations. To accomplish this purpose, the 
MAPSS prototype was logically designed into three functional modules: (1) Concept of 
Operation (CONOPS) Development, (2) Course of Action (COA) Development, and (3) 
Operation Sustainment Dashboard. System requirements for each module were identified 
and validated by current doctrine, formal surveys and interviews with intended users of 
the system. The following system requirements were implemented into the first version 


of the prototype. 
a. Concept of Operations Development 


(1) Users shall initiate Concept of Operation (CONOPS) for aviation 
logistics support for Current and Future Operations, which includes assigning squadrons 
and aircraft to an Operation based on mission analysis and higher headquarters’ 
Operation Order (OPORD). 

(2) Users may/shall initiate multiple Courses of Action (COA) options 
for the Commanding Officer’s decision. Types of COA options shall include Forwarding 
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Operating Bases (FOB), Enroute Support Bases (ESB), Sea bases, Ammunition Supply 
Points (ASP), and Forward Arming and Refueling Points (FARP). 

(3) COA options shall be summarized by type of COA, weight (tons), 
footprint (square-feet), and occupying space (cubic-feet) to aid COA selection by the 
Commanding Officer and the development of Unit Deployment List (UDL) / Time 
Phased Force Deployment Data by the squadron Logistics Department. 


b. Course of Action Development 


(1) Users may/shall assign, update, and remove personnel, spare parts, 
support equipment, and mobile facilities from any COA option defined for an Operation. 

(2) Users may/shall document, update, and remove location 
information for any COA option defined for an Operation. 

(3) Users may/shall document, update, and remove transportation 
information for any COA option defined for an Operation. 

(4) Users may/shall document, update, and remove host nation or unit 
support information for any COA option defined for an Operation. 

(5) Users may/shall document, update, and remove COA specific 
planning and execution tasks for any COA option defined for an Operation. 


c. Operation Sustainment Dashboard 


(1) Users shall view readiness statistics for personnel, repair parts, 
support equipment, and mobile facilities assigned to an Operation/COA for the purpose 
of aiding logistics support replenishment decisions. 

(2) Users shall view readiness statistics for aircraft assigned to an 
Operation for the purpose of aiding logistics support decisions. 

(3) Users shall initiate, update, and remove aeronautical material 
requisitions for aircraft assigned to an Operation for the purpose of requisition 
management. 

(4) Users shall view detailed UDL information (weight, footprint, and 
occupying space) for each COA in order to aid UDL/TDFDD development by the 


Logistics Department. 
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2. Information and Control Flow Diagrams 


There are many different methods of modeling the logical processes of an 
information management system. One effective method for database driven, dynamic 
web-enabled applications is the Information and Control Flow Diagram. The purpose of 
an information and control flow diagram is to depict the control and information flow 
within a system. The MAPSS prototype was developed using information and control 
flow diagrams and used the following notation: rectangular shapes represent web pages; 
dash-lined arrows represent system control, 1.e., hyperlinks, buttons, and/or icons that 
users may select; and solid-lined arrows represent the flow of information in relation to 


the back-end relational database. 
a. MAPSS User Log-on Process 


The MAPSS log-on page allows the user to log-on to the system. Users are 
required to enter a username and password. Both username and passwords are processed 
and checked against a user list in the MAPSS database. Upon successful authentication, 
users are automatically directed to the “start” page of the application. Users who are not 
authenticated are presented with a system feedback page, stating that either their 
username or password is invalid and then given another opportunity to enter a correct 


username and password. 


The MAPSS “start” page has three options for users to select: Current 
Operations, Future Operations, and Past Operations. The current and future options 
allow users to access planning and sustainment functionality for active and near-future 
operations that the MALS is currently planning, has planned previously, or currently in 
the process of sustaining. The Past Operation selection is for inactive or completed 
operations. Maintaining historical records is a significant aspect of the MAPSS 
prototype; it provides a means to identify and analyze logistical trends that could benefit 
current and future planning requirements. Regardless of the option selected, however, 
system functionality and user interface remains consistent for all (current, future, or past) 


options. Figure 24 illustrates the log-on process. 
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Figure 24. User Log-on Process 
b. Concept of Operations Development Process 


The Concept of Operations (CONOPS) development page is the first of 
three MAPSS processes. Defining the overarching CONOPS for a contingency or 
Operation is a result of mission analysis and guidance from higher headquarters [15]. The 
primary purpose of the CONOPS development page is to allow AVLOG planners to 
assign squadrons, aircraft, and establish alternative Courses of Action (COA) options for 
the MALS Commanding Officer’s decision. The CONOPS development page provides 
the interface to the other two processes of the system: COA Development and Operation 
Sustainment Dashboard. 

Additionally, the CONOPS development page allows users to establish 
and maintain an Operation Logbook and 782 Gear List. The Operation Logbook is a 
function that allows users, planners, and decision-makers to chronologically document, in 
a central and globally visible location, the significant events of an operation throughout 
the planning, execution and sustainment phases. The 782 Gear List, although not as 
critical as the Operation Logbook, provides the means for users (especially personnel 
assigned to an operation) to quickly discover what personal and professional items they 
are required to have in their possession when they deploy for the operation. 

The CONOPS development page was developed with robust functionality. 
In addition to assigning and removing squadrons, aircraft, and alternative COAs to and 
from an operation, users have the capability to add, update and delete information for an 


Operation, Squadron, Aircraft, COA, 782 Gear, and Logbook Entry. Although these are 
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basic database functionalities as a stand-alone system, they become more robust; 
however, as system interoperability is incorporated with future versions of the MAPSS 
prototype. For example, Squadron and Aircraft information would be “pulled” from the 
NALCOMIS system, allowing drop-down menus to be populated for the CONOPS 
development/assignment functionality within MAPSS. Conversely, MAPSS was 
developed with the intent to have any added, updated, or deleted Squadron and Aircraft 
data “pushed” to the other interoperable systems, in this example the NALCOMIS 
system. 

System feedback is another important functionality. Since MAPSS is a 
web-centric transaction-based system, users must know the status of transactions; there 
must be timely reactions to all user actions [16]. MAPSS offers concise and informative 
confirmation for all transactions. “Success” pages notify users that they have 
successfully assigned, removed, added, updated, or deleted data from the system. 
Moreover, a hyperlink is provided on each “success” page so users can quickly conduct 
another transaction of the same type or return to the parent process. Figure 25 illustrates 


the CONOPS development process. 
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Figure 25. Concept of Operation Development Process 
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c. Course of Action Development Process 


The Course of Action (COA) development process is the second of three 
MAPSS processes, and is the core capability of the MAPSS prototype. The COA 
development process is an essential and required step in the Marine Corps Planning 
Process (MCPP); the intent is to generate multiple options that will satisfy mission 
requirements and support the overall scheme of maneuver of the MAGTF Commander 
[17]. The purpose of the MAPSS COA development process is to support the decision- 
making process of the MALS Commanding Officer by rapidly and efficiently generating 
suitable and sustainable aviation logistics support packages. 

As mentioned in Chapter I, the foundation of all aviation logistics support 
is personnel, repair parts, support equipment, and mobile maintenance facilities. Thus, 
MAPSS COA development is centered on the assignment and comparison of those 
entities. The COA Development page is designed to display all currently assigned 
personnel, repair parts, support equipment, and mobile facilities for the operation. 
Consistent with the design and purpose of the other MAPSS processes, the COA 
development page also has remove, add, update, and delete functionality for personnel, 
repair parts, support equipment, and mobile facility information. 

Implicit in the development of any COA 1s its distinguishable elements or 
aspects that make one option different or superior over another given certain 
circumstances. Such circumstances may include logistical footprint constraints, limited 
available transportation in theater, time phasing requirements for deployment and 
execution, or host nation support, to name a few. The MAPSS COA development 
process was designed to allow the AVLOG planner the ability build robust and 
distinguishable COA options. Functionality includes the ability to assign notional host 
nation support, transportation to and from points of embarkation and disembarkation, 
multiple deployment locations, and an array of mission-specific execution tasks. 
Effective COA development and comparison is also hastened by aviation logistics 
support package metrics: weight, square-feet, and cubic-feet of each proposed COA. The 
COA development page is a concise yet information rich virtual workspace that allows 
AVLOG planners to introduce as many variables as necessary to develop an array of 
distinguishable aviation logistics support packages. This capability can only benefit the 
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effectiveness of aviation logistics planning and the subsequent decision by the MALS 


Commanding Officer. 


development. 


Figure 26 depicts the logical processes of the MAPSS COA 
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Figure 26. 
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Developing and approving plans are only half of the equation. Executing 


and sustaining deployed forces is vital to mission accomplishment. History is stocked 


full of examples where efficient and responsive logistical support was the difference 


between success and failure of a military campaign. The current environment of smaller 


scale contingencies, asymmetric warfare and distributed inter and intra-theater bases 
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compound the challenges of effectively sustaining friendly-forces. Today’s leaders and 
aviation logistics professionals need a robust decision support tool for today’s complex 


sustainment requirements. 


The MAPSS Operation Sustainment process, referred to as the “Operation 
Dashboard,” was designed to provide the leaders at the MALS level with the visibility to 
synchronize with deployed forces, the ability project future requirements and the 
functionality to actively engage in logistical sustainment. The Operation Dashboard 
employs a stoplight model, giving users near real-time visibility on the status of 
personnel, repair parts, support equipment, mobile facilities, and aircraft. The watch 
(green), plan (yellow), and act (red) model was designed to allow users to quickly 
identify potential problems and prioritize any subsequent action, which saves time and 


valuable resources. 


The MAPSS stoplight decision aid is based on mission capability 
percentages. For example, if a COA has a total of 100 personnel assigned and 10 
personnel are currently ill, injured, or unable to perform their duties, then the mission 
capability for Personnel at that location is currently 90%. Based upon pre-determined 
criteria set for the operation, 90% mission capability could be a green, yellow, or red light 
situation, requiring either no action at all or immediate attention. Regardless of the 
criteria set by the organization, leaders will quickly and accurately know the status of 
deployed forces and equipment, a major improvement over current manual processes. 
The mission capability percentages are derived from data maintained in the MAPSS 
relational database. For personnel, repair parts, support equipment, and mobile facilities, 
“current status’ is documented upon assignment to a COA and updated as required 
throughout the operation, a function that is provided on the Operation Dashboard 
interface. Aircraft mission capability percentages, on the other hand, are more complex 


and derived from the Aircraft Material Readiness Report (AMRR). 


The combat readiness of the MAGTF ACE and the sustainment necessary 
for continuous combat operations is the MALS mission. Thus, the AMRR is the key 
readiness indicator fora MAGTF ACE and 1s often regarded as the MALS’ report card 


for an operation. The purpose of the AMRR 1s record the material support requirements 
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that are currently on order preventing an aircraft from full mission capability status. The 
AMRR includes information about the aircraft, the part ordered, and the current status of 
the requisition in the logistics supply chain. The MAPSS AMRR functionality allows 
users to quickly add, update, and delete requisition data, which in turn is reflected in 
updated aircraft mission capability readiness percentages and the stoplight indicators. 
MAPSS provides extensive requisition management features, allowing users, regardless 
of time and space, to actively engage in the logistical sustainment of deployed forces. 
This web-enabled interface is dramatic departure from the current redundant and 


ineffective “‘flat-file” technology processes used to sustain aviation logistics forces. 


In addition to identifying what the potential issues are, the Operation 
Dashboard includes reports that explain why, providing more in depth information on 
each component of an operation. Continuing the above example, a Personnel Report 
would identify all non-mission capable personnel by name, military occupational 
specialty, social security number, and reason for their current status. Detailed reports are 
enabled for personnel, repair parts, support equipment, mobile facilities, and aircraft; an 
executive summary is also available. Moreover, MAPSS reports are printer-friendly, so 
users have the option to view them online or print them at their convenience. The 
MAPSS reports provide clear and relevant information and, most importantly, another 


layer of decision-support for the aviation logistics community. 
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Figure 27. Operation Sustainment Process 


This chapter discussed the RAD methodology and the significance of Microsoft 
Access 2003, Microsoft Visio 2003, and Macromedia Dreamweaver MX 2004 as 
development tools. This chapter also presented the graphical representations of how data 
is physically stored in the relational database and how data is manipulated and processed 
to accomplish system requirements for the aviation logistics warfighter. Although 
models represent a view of reality, it 1s the implementation and deployment of a system 


that determines the level of reality that has been met, which is the topic of Chapter V. 
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Ve PROTOTYPE IMPLEMENTATION AND DEPLOYMENT 


This chapter discusses interface and web design features that were considered 
during the implementation of the MAPSS prototype. Deployment feedback received by 
the aviation logistics professionals that agreed to participate in this researched is also 


discussed. 


This chapter is organized as follows. Section A describes the importance of 
typography, color scheme, cascading styles sheets, templates, navigation and information 
structure in web design; and Section B discusses the benefits of end-user interaction 
within the prototyping process, and then describes the positive feedback and constructive 
criticism received for the first iteration of the prototype. 


A. INTERFACE DESIGN CONSIDERATIONS 


Designing the user interface is vital to the success of any web-centric application; 
it is the difference between a system that gets used regularly, reluctantly, or not at all. In 
addition to the user’s functional needs and system requirements, there are some 
universally accepted concepts of web design that should be considered: (1) clear and 
readable typography, (2) consistent color scheme, (3) effective navigational structure, and 
(4) logically organized information. 


1. Typography and Color Scheme 


In broad terms, typography refers to the use of typeface and font, the former is the 
style of text (i.e. Times New Roman, Arial and Verdana) and latter is the physical size of 
the typeface (i.e. 10, 12 and 14 point font). Typeface and font sizes should be considered 
and selected early and maintained throughout the development process, using too many 
techniques at one time only leads to screen clutter and the impression of confusion [16]. 
Both typeface and font size, if used consistently, provide an effective and legible web 
interface for users. 

Color scheme is another important consideration. When used properly, color can 
enhance the presentation of your information, providing structural and navigational clues 
for the user. Conversely, poor use of color distracts from content and can annoy users 


[18]. Color schemes and the subsequent effect on the user’s cognitive processes is a 
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highly specialized and technical field, which is beyond the scope of this thesis. A good 
rule of thumb, however, is to select contrasting colors for text and backgrounds. To 
maximize legibility, light colored text against dark backgrounds or dark colored text 
against light colored backgrounds should normally be used. 

Both typography and color scheme were a deliberate design consideration in the 
development of the MAPSS prototype. Verdana was selected as the typeface. It is an 
appropriate typeface for web applications because it is an expanded typeface, meaning 
that each letter takes up more horizontal space on the page making it much easier to read 
(and thus comprehend) compared to other typefaces. The tradeoff, however, is that it 
may increase the vertical length of web pages and lead to the use of the scroll bar to see 
all of the presented information. For the MAPSS prototype, the positives outweighed the 
negatives; dark colored (#990000) Verdana typeface against a light colored background 
(#FFFFCC) was chosen. The following figure illustrates the typography and color 
scheme for MAPSS prototype. 
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Figure 28. Typography and Color Scheme 


Font sizes were also considered in the development of the prototype with the 
purpose of maintaining consistency. ont sizes are important not only for legibility 


purposes, but also because they provide hierarchical structure and act as navigational 
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clues for users to effectively traverse the system. Font sizes can be used to separate 
major sections of text such as headings and sub-headings or be used to display system 
functionality such as hyperlinks. 

The basics of web design, clear and readable typography and a consistent color 
scheme, is easily implemented and maintained by recent improvements in web 
development technology. Two examples are the use of templates and cascading style 
sheets (CSS). Templates are used to maintain static or unchanging aspects of pages 
within a site (1.e., graphics, images, and navigational links) while allowing developers to 
add content to “unlocked” sections of pages [19]. The end result is a consistent intra-site 
web design and not the perception of multiple web pages linked together. Dreamweaver 
MX 2004 provides excellent functionality for using templates, which includes creating, 
updating, and, if needed, quickly removing templates from web pages. The following 


figure depicts the MAPSS template that was used throughout the development process to 


create the consistent “look and feel” for the prototype. 
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Figure 29. Template Displayed in Dreamweaver MX 2004 


Another important web technology is Cascading Style Sheets (CSS). 


In fact, 


“CSS is the preferred method of controlling the layout and design features of a modern 
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web site” [19]. CSS is best described as an external set of rules that can be applied to as 
many web pages as needed—literally thousands. CSS are the blueprints of how 
information is displayed on a user’s screen. This is a powerful and extremely efficient 
tool for web developers. For example, an organization may want to update or change its 
theme on all of its web pages, maybe change from a Times New Roman to an Arial 
typeface. Using CSS, this can be done in a matter of minutes simply by editing a single 
style sheet. Comparing this process to those in the past, where changes were laboriously 
made to each and every web page, the benefits and efficiency of using CSS quickly 
become apparent. CSS is rapidly revolutionizing web design and site maintenance; it 
allows organizations to efficiently control the style and theme of their web presence in a 
dynamic environment, which in today’s highly competitive atmosphere can be the 
difference between prosperity and mere survival. CSS was used in the development of 
MAPSS. All regular text, headings, hyperlinks, menus, textboxes, forms and tables for 
the prototype were developed and maintained using a master style sheet. Although all 
web developers can benefit from the use of CSS, it 1s especially conducive for developing 
prototypes where numerous changes are expected and expected often. 


De Navigation and Information Structure 


Typography and color scheme are only one aspect of user interface design; a well- 
organized navigational structure and logically organized information are vital attributes 
for an effective web-centric application. In Principles of Web Design, Joel Sklar outlines 
the requirements for creating usable system navigation: (1) users should always know 
where they are, (2) users should always know where they can go, (3) users should always 
know how to get there, and (4) users should always know how to get back to where they 
started. The author also leaves little doubt about the importance of logically organizing 
information on the web page: “information design is the single most important factor in 
determining the success of your site” [18]. 

As discussed in Chapter IV, MAPSS consists of three modules; therefore, the 
navigational structure of the application is aligned with the functional requirements of 
developing Concepts of Operation (CONOPS), Courses of Action (COA), and sustaining 
deployed aviation logistics forces. An intentional development strategy for the prototype 
was to incorporate a navigational structure that was consistent with the natural workflow 
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of current planning and sustaining processes of the MALS. The following figures 


illustrate the interfaces of the three modules of the MAPSS prototype. 
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Figure 30. Concept of Operations Development Page 
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The figures above reflect a coherent navigational structure and a logically 
organized text-based informational design. All three modules are consistent, each having 
a navigation side-bar on the left side of the page and relevant text-based information 
arranged in table format, which is neatly framed within color-coded blocks with 
appropriate headings describing the enclosed content. The position of the navigation bar 
on the left side of the page is a proven web usability technique. In a recent usability 
study of both novice and experienced web users, over 60% of the users expected internal 
links to be positioned on the left side of the page [20]. Hence, the design of the MAPSS 
system takes advantage of a familiar web navigation convention for both novice and 
experienced users. 

The MAPSS prototype also measures well against Sklar’s criteria for usable 
system navigation. First, users of MAPSS should not have a problem identifying “where 
they are’ in the system. Every web page has clear headings at the top of the page which 
describes its purpose. Location paths are also employed to assist users in maintaining 


their orientation within the system. The following figure depicts the concept. 
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Figure 33. Use of Location Paths 
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Location paths are an effective design technique to aid users with system 
situational awareness. In the example above, the user has navigated from the Start page, 
to the Operations List, Operation Details, and currently working with the Assign Aircraft 
to Operation page. The location path in the figure above also serves a dual purpose, 
which conforms to Sklar’s fourth criteria: “Users should always know how to get back to 
where they started.” Part of the location path is a hyperlink back to the Start page of the 
system, the launching point for all modules of the MAPSS prototype. In addition to 
location paths, a “home” hyperlink is also provided on each page under the MAPSS 
banner. 

Sklar’s other two measures of effectiveness, users should always know “where” 
they can go and “how” to get there, are accomplished as well. As previously discussed, 
each system module has a navigational side bar located on the left side of the web page 
that contains all relevant “where” information for that module’s functionality. The fact 
that all the “where” information is also a hyperlink inherently provides the “how” 
information as well. Furthermore, all of MAPSS’ functionality 1s accessed from just 
three web pages, so the user’s situational awareness is easily maintained and any “where” 
and “how” information that users may need 1s just a mouse-click away. 

The last two design considerations are related to efficient information structure. 
As discussed in Chapter III, current aviation logistics planning is a manual and time 
consuming process resulting from the lack of systems integration; planners are required 
to access multiple information management systems to source aviation logistics support 
plans. By far, the most significant aspect of the MAPSS prototype is the four-into-one 
system integration design; MAPSS combines the data sets from four different systems 
into one logically organized user interface. The COA development page, depicted in 
Figure 31 above, demonstrates the systems integration concept, where information on the 
page represents integrated data for entities (from system): Personnel (MCTFS), Repair 
Parts (NALCOMIS), Support Equipment (IMRL), and Mobile Facilities (TBA). This 
functionality alone has the potential to be a mission multiplier and increase the efficiency 
of planning and sustaining deployed forces. 

The last design consideration is the presentation of the information. System 


requirements are essential for any system design; however, location of the user and how 


SF 


he/she interfaces with the system is equally important. With this in mind, MAPSS was 
designed as a low-bandwidth system; the interface is predominately text-based. Although 
detailed graphics, multimedia and other interactive features attract and make web sites 
more aesthetically appealing, these features come with a cost—bandwidth. Bandwidth is 
a precious commodity in the armed forces, especially for deployments in austere 
locations. As result, the MAPSS prototype was intentionally designed to maximize the 
bandwidth-friendly characteristics of text. The prototype was designed for a baseline 
56K bps data connection, which is a common constraint in today’s environment using 
organic communications such as the INMARSAT system, aboard an LHA/LHD with a 
MEU, or operating on a T-AVB ship. MAPSS, as a text-based system, allows users to 
quickly access and complete necessary transactions which lead to an increased combat 
readiness of the MAGTF ACE. Deployed aviation logistics personnel cannot be hindered 
by time-consuming downloads of images, graphics or multimedia in their march for 
mission accomplishment. 


B. PROTOTYPE DEPLOYMENT AND FEEDBACK 


The benefit of the RAD methodology is the iterative process of designing, testing, 
and refining the potential system. User involvement is the cornerstone requirement for 
every prototype. Both developers and users benefit from the interaction. Developers can 
identify and solve design and functionality issues earlier in the system development 
process, which is conducive to delivering a system on time and on schedule. Users, on 
the other hand, can identify and refine actual system requirements before the system is 
delivered and does not do what was expected or needed. “The basic principle behind 
prototyping is that users know what they want when they see it working” [10]. 


1. Prototype Deployment 


The active end-users for the first iteration of the prototype were Operations 
Officers from MALS-11 and MALS-36. Both field-grade officers agreed to participate in 
this research and provide the necessary feedback on the prototype. As mentioned in 
Chapter III, MALS Operations (S-3) Officers are the lead planners for aviation logistics 
at the tactical-level; hence, they are primary intended users of the system. 

The ideal situation for any prototype implementation is face-to-face interaction 


between the developer and the user. Face-to-face interaction allows developers to clearly 
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explain and demonstrate the system and provide any necessary training. For much of the 
same reasons, users benefit from face-to-face interaction because it 1s an opportunity to 
get important questions answered quickly and clearly express any issues, problems or 
suggestions that arise with the system. Overall, face-to-face interaction is beneficial to 
all involved and sets the tone for smooth transitions of future prototype iterations. 
Unfortunately, face-to-face interaction was not a possibility for the MAPSS prototype. 
Funding, operational tempo and the geographic divide made face-to-face interaction for 
this iteration improbable. Considering the prototype is a web-enabled application, 
however, the impact was lessened considerably. Users accessed the system via the 
Internet, which was a test of system design and capability in and of itself. 

The MAPSS prototype was hosted on a web server in the Database and Web 
Technologies Lab at the Naval Postgraduate School. The web server provided unlimited 
and uninterrupted access during the development and deployment of the prototype. 
Before access (username and password) was granted to users, a pre-deployment brief was 
provided to both squadrons. The intent of the brief was to explain the purpose of the 
prototype, discuss the design of the system, and define all system functionality. 
Conceptual data models, logical process models, and multiple screenshots of the system 
were provided. Users were encouraged to get all questions answered when arisen, either 
prior to accessing the system or during the evaluation period. 

The deployment of the first version of the MAPSS prototype had the following 
objectives: (1) confirm initial systems requirements, (2) collect any new or refined 
system requirements, and (3) test the usability features of the prototype. To facilitate the 
evaluation of the prototype, the MAPSS web-enabled application contained several 
fictitious operations, all in various stages of development. Some operations were fully 
developed, meaning all modules (CONOPS, COA and Dashboard) contained data while 
other operations were in the initial or definition stage of development. Users were 
instructed to browse and test all functionality of the system. They were given the 
freedom to add, update, delete, assign, and remove data as they saw fit. Users were given 


a two-week period to evaluate the first version and provide the necessary feedback on the 
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system. Although face-to-face interaction did not occur, the evaluation period was 
considered a success: concise, insightful, and constructive feedback was attained that can 
be used to further improve the system. 


2. Prototype Feedback 
a. Positive Feedback 


Overall, the feedback received for a first version of the prototype was 
positive, which was very encouraging. The overarching design concept of using three 
different modules (CONOPS Development, COA Development, and Operation 
Dashboard) was favorably received. The following are some positive comments received 
about the MAPSS prototype: 

(1) The ability to compare COA by weight, square-feet, and 
cubic feet is good feature because limited availability for lift 1s always an issue for 
getting AVLOG in theater. 

(2) The Operation Dashboard is a_ nice function for 
distinguishing problems or areas of concern for personnel, parts, support equipment, 
mobile facilities, and aircraft. It is a needed element, especially for other horizontal and 
vertical commands to quickly grasp current status. 

(3) The ability to perform material requisition management is a 
nice feature. 

(4) The system is easy to navigate. 

(5) The font and color scheme combine to make the system 
easy to read. 

(6) Information was very logically organized. 

(7) The low-bandwidth design is a must for operational forces. 
The interface should be as simple as possible due to the possibility of having extremely 
low-bandwidth at deployed sites. 


b. Constructive Criticism 


Like most first version prototypes, there was no shortage of constructive 
criticism. Successfully implementing all system requirements and having a completely 


functional system is highly unlikely and simply unrealistic with the first iteration of any 
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prototype. Constructive feedback is essential; it is one of the primary benefits that 
prototyping has over other system development methodologies. Feedback should be 
collected, considered, and used to further improve the system. The following is the 
constructive criticism received on the MAPSS prototype: 

(1) Assigning the same personnel, parts, support equipment, 
and mobile facilities to multiple COA options is a tedious process. The system needs the 
capability to assign individual support components to multiple COA options with one 
transaction. 

(2) The system should automatically generate a generic COA 
shell based upon initial CONOPS development. The system needs the capability to 
import logistics pack-ups or groups of personnel, parts, support equipment, and mobile 
facilities. 

(3) Course of action comparison would be more efficient if 
displayed side-by-side on a single web page instead of toggling back and forth. 

(4) Mouse-over messages are needed for red and yellow lights 
on the Operation Dashboard, which would explain why mission-capability is low. 

(5) Suggest a different but consistent color scheme for each 
logistics support component. For example, the color blue for parts, gray for support 
equipment, and orange for personnel information. Color-coding would allow users to 
quickly identify a particular section of interest. 

(6) The CONOPS Development module needs the functionality 
to add more narrative for an operation, such as commander’s intent, type of mission, and 
operational assumptions. 

(7) The UDL/TPFDD summary needs some refinement to 
make it MDSS-II compatible. 

The evaluation of the first iteration of the MAPSS prototype was 
beneficial. It revealed that the web-centric application is a viable product that should be 
further developed to meet the needs of the aviation logistics warfighter. It was an 
Opportunity to assess what the system did well and what areas need improvement. The 
evaluations by both Operations Officers were instrumental in paving the future direction 


of the system. The road ahead involves more analysis, more development, more 
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refinement, and more testing. This version is just the first of many prototypes that will 
ultimately lead to a system that satisfies tactical-level aviation logistics planning and 
sustainment requirements. Prototype development must continue in parallel with the 
current aviation logistics transformation of the Marine Corps. In short, the road ahead is 


long but necessary. 


This chapter discussed the user interface and web design features 
that were considered during the implementation of the MAPSS prototype as well as the 
deployment feedback received by the aviation logistics professionals of MALS-11 and 
MALS-36. The deployment and subsequent feedback on the first prototype iteration was 
an essential step in the application’s development cycle. Another key research activity 


accomplished for thesis was a usability study, which is the subject of Chapter VI. 
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VI. USABILITY TESTING 


This chapter describes the methodology, experimental design, and test metrics of 
the usability study that was accomplished on the MAPSS prototype. The results of the 
usability study and its contribution towards improving system effectiveness, efficiency, 


and user satisfaction are also discussed. 


This chapter is organized as follows. Section A describes the “who, what, when, 
where, and why” of the usability study; Section B describes the interaction between test 
equipment, participants and administrators; Section C describes the test metrics that were 
captured during the study; and Section D is the analysis of system effectiveness, 
efficiency, and user satisfaction. 


A. METHODOLOGY 


The primary objective of the usability study was to evaluate the effectiveness, 
efficiency, and satisfaction with which specified users can achieve specified goals in a 
particular environment [21]. The usability test was focused on user interaction as it 
relates to system functionality, navigation, design, and information architecture, which 
could then be used as a baseline for future prototype iterations. 

The usability test was conducted at the Database and Web Technologies Lab, 
Naval Postgraduate School, Monterey, California, on May 17, 2006, between the hours of 
0800-1300. The study was facilitated by a test administrator and two observers, whose 
primary responsibilities were to collect test metrics of the study. Five participants were 
selected on a voluntary basis to participate in the study. Three participants (60%) were 
Marine Corps Officers with primary military occupational specialties (MOS) in Marine 
Corps Aviation; two of which were Aviation Logistics Officers, intended users of any 
future fielded system for aviation logistics planning and sustainment. One participant 
was a Marine Corps Communications Officer with extensive deployment experience and 
intimately familiar with the Marine Corps Planning Process (MCPP). The fifth 
participant was an international officer from the Hellenic Navy. The value of including 
an international officer in the study, where the English language was not his/her native 


language, was to capture the overall intuitiveness and ease of use of the prototype. 
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The usability study was approved by the NPS Institutional Review Board, an 
entity that maintains oversight when human subjects are involved in any research at the 


Naval Postgraduate School. Test equipment for the usability test consisted of the 


following: 
® The MAPSS prototype application and supporting Database running under 
Microsoft Access 2003. 


® Client Computer: Pentium III/600 MHz processor, 512 Mb RAM, 
Microsoft Windows NT 2000 Professional operating system, 15” LCD monitor with 
resolution settings of 1024 x 768 pixels. 

® Host Computer: Dual Pentium IV/2.8 GHz processor, 2 Gb RAM, 
Microsoft Server 2003 Enterprise Edition operating system. 

® Web-browser(s) on Client: Microsoft Internet Explorer v6, Mozilla 
Firefox v1.5. 

e Network: 100 Mbs Ethernet; Client IP address: 131.120.178.78; Host IP 
address: 131.120.251.70; Domain: ebiz.nps.navy.mil. 

e Two Digital video cameras with tripod. 


B. EXPERIMENTAL DESIGN 


The client workstation was setup with one digital video camera recording the on- 
screen transactions of the participant, and a second digital video camera was setup to 
record the facial expressions of the user. Both digital video cameras were equipped with 
microphones; audio was recorded to capture user comments. All participants signed a 
consent form and privacy act statement, authorizing audio/video recording for 
educational purposes and to ensure the identity of each participant was protected against 


unauthorized disclosure. 
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Figure 34. Usability Test Experimental Design 


The experiment consisted of three phases: Concept of Operation Development, 
Course of Action Development, and Operation Sustainment. All participants were given 
scenario-based tasks to complete for each phase of the experiment. Participants were also 
encouraged to “think aloud,” verbalizing their actions, thoughts, and any aspects of the 
task that may have been troubling to complete. Prior to starting the first phase of the 
experiment, participants were given five minutes to familiarize themselves with system 


functionality and navigation. 


The administrator was on hand to facilitate the overall experiment and to provide 
user assistance with the system, if necessary. Participants were instructed to make three 
attempts at completing a task before requesting assistance from the administrator. 
Observers were also on hand to record the metrics for the experiment. After 
attempting/completing all scenario-based tasks, participants completed a post-experiment 
user survey. 

C. TEST METRICS 

The following test metrics were captured during the study as a means to analyze 

the usability and functionality features of the prototype. 


1. System Effectiveness 
a) Did the participant complete the task successfully? (Yes/No) 


b) Did the participant require assistance from the administrator to 


complete the task? (Yes/No) 
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C) What type of assistance was provided? (e.g. definition of a term or 
acronym, clarification of a requirement related to the scenario-based task, and/or 


correctly navigating to complete the scenario-based task) 


d) Number of occurrences for assistance required for completing a 


task. 


e) Number of application or system errors (e.g. incorrect data 
displayed or a page failed to load). 
Zz: System Efficiency 


a) Time (seconds) to complete an individual scenario-based task. 

b) Number of mouse-clicks to complete an individual scenario-based 
task. (e.g. clicks on hyperlinks, web page or browser buttons or icons) Note: a double- 
click to initiate an action was equivalent to one click. 


3. System Satisfaction 


a) All participants completed a post-experiment survey. 


D. USABILITY TEST RESULTS 
1. System Effectiveness 


The usability test was designed to examine the major functionality components of 
the system: CONOPS Development, COA Development and Operation Sustainment. 
User participation for the study was designed for one-hour duration. [Each participant 
was asked to complete 19 scenario-based tasks encompassing the most significant system 
requirements. As a result, with five participants in the study, there were a total of 95 (19 


x 5) possible tasks to be assessed. 


The results of the first metric for system effectiveness were very encouraging. All 
participants of the study were able to successfully complete all 19 scenario-based tasks. 
Although 100% of the tasks were completed successfully, assistance from the 
administrator was required for 20% of the tasks attempted; there were a total of 19 
scenario-based tasks, an average of one task per participant where assistance from the 
administrator was required. Hence, 80% of all scenario-based tasks were completed 


without assistance. The majority of assistance occurred during the first phase of the 
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experiment: CONOPS Development. Assistance required at the beginning of the 
experiment was mainly attributed to the general unfamiliarity participants had with the 
system and its navigation architecture. All participants had never seen or used MAPSS 
previously and only received five minutes to familiarize themselves with the system prior 
to the experiment. As the experiment progressed, however, less assistance was required 


due to the participant’s increased knowledge of the system and its functionality. 


The next system effectiveness metric that was captured during the study was 
system errors. The intent was to capture any system bugs or errors in the web-enabled 
database which would prevent participants from successfully completing a task. Ninety- 
four (94) of 95 scenario-based tasks were completed without a system error. The single 
(1) system error occurred during the COA Development phase of the experiment, where a 
participant attempted to assign a part toa COA. The correct procedure for the task called 
for assigning a particular part to a COA with both “on-hand” and “allowance” quantities 
having a numeric value, since both “on-hand” and “allowance” quantities are required 
fields in the database schema. However, the participant submitted the “assign to COA” 
form without inputting a value for the “allowance” quantity which resulted in the system 


Crror. 


The system error was result of the “assign part to COA page” not having the 
proper form validation procedures implemented, an oversight in the development of the 
web page. To prevent system errors of this nature, the active server page should first 
validate that all required fields on the form have acceptable values, and only then submit 
the data to append the database. This error was quickly corrected by implementing the 
proper form validation code to the active server page, ensuring that both “on-hand” and 
“allowance” values had acceptable numeric values before submitting the data to append 
the database. Nonetheless, the study was completed with just a 1% error rate, very 
acceptable for a first-version prototype. 


2. System Efficiency 


The purpose of capturing the time and number of mouse-clicks (amount of effort) 
it took for participants to complete the scenario-based tasks was to identify trends and 


potential navigation problems with the usability of the system. In the analysis of the data, 
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three navigation issues were identified by the high standard deviation of time and number 
of mouse-clicks it took the participants to complete the scenario-based task. Table 2 


illustrates the three potential issues identified during the usability test. 


| Phase | Task _—_| Time (seconds) 
CONOPS Development | Assign Squadron to Operation a 


CONOPS Development | Assign Aircraft to Operation 102.3 
COA Development Assign Personnel to COA 


Table 2. Potential Issues Identified During The Usability Experiment 





The first two issues occurred during phase one (CONOPS Development) of the 
experiment. Aside from initially logging into the system to start the experiment, 
assigning squadrons and aircraft to the operation were the first two scenario-based tasks 
to be attempted/completed. The third issue, assigning personnel to a COA, was the first 


scenario-based task in phase two (COA Development) of the experiment. 


Two factors may explain these potential issues. First, as previously discussed, 
each participant was given just five minutes to familiarize themselves with the system; 
hence, initial tentativeness, apprehensiveness and caution were expected and experienced 
in each phase of the usability test. As the study progressed and participants became more 
comfortable with the navigation of the system, the standard deviation of time and mouse- 
clicks to complete each task decreased significantly. For example, scenario-based tasks 
in phase two required participants to assign personnel, repair parts, support equipment, 
and mobile facilities toa COA. The standard deviation for assigning personnel alone was 
75.5 seconds and 14.6 mouse-clicks, but the average standard deviation for assigning the 
remaining repair parts, support equipment, and mobile facilities decreased to 22.2 
seconds and 5.4 mouse-clicks, a decrease in time and amount of effort of 71% and 63% 
respectively. This decrease is a clear indication that participants of the usability study 
were learning the navigation architecture of the system and beginning to use it 


effectively. 
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System navigation architecture is another factor that may explain the potential 
issues identified in Table 2. As mentioned in Chapter V, each module of the system is 
designed with a navigation side-bar on the left side of the web page that includes 


hyperlinks to all relevant functionality for that module. 
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Figure 36. COA Development usability issue 


As depicted in Figures 35 and 36, multiple hyperlinks are provided for each 
component of the module. Although all modules are consistently designed, participants 
of the usability study experienced problems differentiating between the “add” and 
“assign” functionality of the system; therefore, a few participants of study spent a 
considerable amount of time and mouse-clicks incorrectly “adding” personnel to the 


system instead of correctly “assigning” personnel to the COA. 


Future iterations of the prototype may benefit from a re-design of the navigation 
architecture. One potential solution is to develop a fourth module, a “System 
Administration” module where basic database management functionality (for all 
interoperable systems) is included on one web page. This redesign would eliminate all 
system management functionality from the three primary modules, which could 
potentially reduce any visual and/or logical ambiguity for users. The trade-off, of course, 
is a fourth module to design, create, update and maintain. This redesign, however, would 
have minimal impact on the current data and logical process models of the system. Most 
importantly, the redesign would be largely transparent to the intended users of the 


system. 


3. System Satisfaction 


All participants of the usability study completed a post-experiment survey. The 
survey was designed to capture the participant’s degree of satisfaction with the 
prototype’s functionality and usability features. The survey consisted of 23 questions: 15 
pertaining to system functionality and nine questions relating to the general usability 
features of the system. Participants were asked to indicate their level of satisfaction using 
a four-point rating scale. 


Rating 


Dissatisfied 


Satisfied 





Extremely Satisfied 


Table 3. Post-Experiment Survey Metrics 


Although data from such a small pool of participants did not provide the basis for 
any significant statistical analysis, it did provide valuable and insightful information that 
can be used for implementing future enhancements to the prototype. The results from the 
post-experiment survey were overwhelmingly positive: the average score for system 
functionality was 3.59 and system usability received a score of 3.40. Both scores indicate 
that users were “satisfied” with the first version of the prototype. The following 
illustrations indicate the level of satisfaction from each functionality/usability aspect that 
was assessed during the study; all respondents completed the survey immediately 


following the usability experiment. 
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Extremely Dissatisfied Dissatisfied Satisfied Extremely Satisfied 


Figure 37. Survey Results: Initiating CONOPS 





Extremely Dissatistied Dissatistied Satistied Extremely Satisfied 
Figure 38. Survey Results: Assigning Squadrons to Operation 





Extremely Dissatistied Dissatistied satistied Extremely Satistied 


Figure 39. Survey Results: Assigning Aircraft to Operation 
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Extremely Dissatistied Dissatisfied Satisfied Extremely Satistied 


Figure 40. Survey Results: Establishing Multiple COA for Operation 





Extremely Dissatisfied Dissatisfied Satisfied Extremely Satisfied 


Figure 41. Survey Results: Assigning Personnel to COA 





Extremely Dissatistied Dissatisfied satistied Extremely Satistied 


Figure 42. Survey Results: Assigning Parts to COA 
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Extremely Dissatistied Dissatisfied Satistied Extremely Satistied 


Figure 43. Survey Results: Assigning Support Equipment to COA 





Extremely Dissatistied Dissatistied Satistied Extremely Satistied 


Figure 44. Survey Results: Assigning Mobile Facilities to COA 





Extremely Dissatistied Dissatisfied Satistied Extremely Satistied 


Figure 45. Survey Results: Ability to Compare Multiple COA 
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Extremely Dissatisfied Dissatistied satisfied Extremely Satisfied 


Figure 46. Survey Results: Ability to Distinguish Problems 





Extremely Dissatistied Dissatistied Satistied Extremely Satistied 


Figure 47. Survey Results: Ability to Determine Causes of Problems 





Extremely Dissatistied Dissatisfied satistied Extremely Satistied 


Figure 48. Survey Results: Ability to Identify Mission Capability Percentages 
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Extremely Dissatistied Dissatisfied catistied Extremely Satistied 


Figure 49. Survey Results: Ability to Modify Material Requisitions 





Extremely Dissatisfied Dissatisfied Satisfied Extremely Satistied 


Figure 50. Survey Results: Ease of System Navigation 





Extremely Dissatisfied Dissatisfied Satisfied Extremely Satistied 


Figure 51. Survey Results: System Feedback Methods 
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Extremely Dissatisfied Dissatisfied Satisfied Extremely Satistied 


Figure 52. Survey Results: System Typography 





Extremely Dissatistiad Dissatisfied Satisfied Extremely Satistied 


Figure 53. Survey Results: System Color Scheme 





Extremely Dissatistied Dissatisfied Satistied Extremely Satistied 


Figure 54. Survey Results: System Structure and Theme 
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Extremely Dissatistied Dissatisfied Satisfied Extremely Satistied 


Figure 55. Survey Results: Consistent System Design 
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Figure 56. Survey Results: Organization of Information Presented 





Figure 57. 


Extremely Dissatisfied Dissatisfied Satisfied Extremely Satistied 


Survey Results: Ability to Drill-Down for Additional Information 
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Extremely Dissatistied Dissatisfied Satistied Extremely Satistied 


Figure 58. Survey Results: Low-Bandwidth Design 


All participants of the usability experiment were either “satisfied” or “extremely 
satisfied” with the basic functionality processes of prototype. However, four usability 
aspects received at least one “dissatisfied” response. The four potential usability 
problem-areas discovered were: (1) color scheme, (2) typography, (3) organization of 
information and (4) system feedback methods. Video and audio recordings of the 
experiment coupled with open-ended feedback on the post-experiment survey were 
essential in not only identifying potential usability problems, but also providing potential 


usability solutions. 


The prototype’s problem with color scheme and typography referred to the 
navigation side-bar on the three modules of the system: CONOPS Development, COA 
Development, and Operation Sustainment. Feedback from participants revealed that 
color scheme and font size (typography) for the navigation side-bar made hyperlinks 
particularly hard to read. In the past, correcting color schemes and typography involved a 
significant amount of effort on the developer’s part—tediously changing hundreds of 
html tags to reflect the new color and/or font style. Today, however, cascading style 
sheets (CSS) allow many aspects of the system to be changed instantly with minimal 
effort [19]. Color scheme and typography are important aspects of any system design, 
but since they are easily manipulated using the latest web technology, these potential 


problem-areas are considered minor issues. Moreover, the MAPSS prototype was 
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developed using CSS; therefore, the developer of future iterations of the prototype can 
quickly manipulate the color scheme and typography to satisfy intended users of the 


system. 


The other two areas of the prototype that received negative feedback were 
“organization of information” and “system feedback methods.” The feedback on the 
organization of information was particularly disconcerting since any effective decision 
support system is largely dependent upon logically arranged information. Organization 
of information should be a primary system design consideration; it could be the 
difference between a system that gets used regularly and a system that gets abandoned by 


intended users. 


The usability experiment also uncovered a design flaw with the MAPSS 
prototype: user interaction and the level of effort to accomplish a task were dependent 


upon monitor resolution. The following figures illustrate the problem: 
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Figure 59. Information Display on 1024 x 768 Resolution Monitor 
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Figure 60. Information Display on 1280 x 768 Resolution Monitor 


In Figures 59 and 60, the difference in user interaction and level of effort was 
significant for usability participants using a monitor with resolution setting of 1024 x 768 
versus a monitor with a 1280 x 768 resolution. Users with the lower resolution monitor 
are required to use the scroll bar to input data in all required data fields and submit the 
form. On the other hand, users with the higher resolution monitor have full access to all 
data fields and the ability to submit the form upon initial load of the web page. The core 
functionality remains unchanged, but users with a high resolution monitor use 
significantly less effort to perform the same operation in the system. Although this issue 
may seem like a minor inconvenience to users with a low resolution monitor, the problem 
is compounded by the repetition of the task (e.g. a user is required to add 50 or 100 


personnel to the system). 


Good system design dictates that user interfaces should be designed to fit the most 
common window or monitor resolutions, not just optimized for a specific sized monitor 
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or resolution setting [16]. MAPSS was designed, developed and optimized for 1280 x 
768 resolution; it was not until the usability experiment that the prototype was 
extensively used and tested with a 1024 x 768 resolution monitors. As a result, future 
iterations of the prototype will require some redesign so effective usability is not 
resolution dependent. Fortunately, not all web pages for the system need to be 
redesigned. Changes are limited to pages that currently require a lot of vertical space to 
display all the data fields. The following system functionality is affected and should be a 


priority for future prototype iterations. 
1. Add Squadron to the System 
2. Update Squadron to the System 
3. Add Personnel to the System 
4. Update Personnel to the System 
5. Add Parts to the System 
6. Update Parts to the System 
7. Assign Transportation to COA 
8. Assign Host Nation Support to COA 
9. Assign Task to COA 


Although multiple pages are affected, data and logical process models remain 
unchanged for the system. Redesign would be focused on changing the structure of 
presented information to a more horizontal orientation. Figures 59 and 60, display a 
significant amount of “white-space” available for the redesign. This redesign would 


definitely benefit users with lower resolution settings. 


The last aspect of the prototype to receive constructive criticism was “system 
feedback methods.” MAPSS is web-based transaction-oriented application; therefore, 
system feedback is an essential element of the system and was implemented into every 
module of the system. Users are notified via system feedback messages anytime data is 
successfully added, updated, or deleted from any web page within the system. The 
following figure is an example of MAPSS system feedback. 
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Figure 61. System Feedback Methods 


The critique received during the usability experiment was more a result of 
MAPSS being a text-based and first-version prototype. Two participants of the study 
noted that system feedback methods were effective, but wanted to see buttons instead of 
hyperlinks, and wanted keyboard shortcuts to select the “YES” or “NO” options. 
Keyboard shortcuts are an effective means for experienced users to perform routine 
actions, and both buttons and keyboard shortcuts should be included in any fielded 
aviation logistics planning system in the future. However, for a first-version prototype, 
keyboard shortcuts (at least in this author’s opinion) is an advanced feature better suited 
for when all system functionality is firmly cemented and aligned with customer 
requirements. System feedback methods will evolve as the prototype evolves into a more 


efficient system. 


The prototype also received positive feedback from the usability experiment. 
Participants of the study noted that the prototype was very easy to use with just a couple 
of minutes of instruction, a good decision support tool for the commander, an extremely 
user-friendly application, and a viable product that the aviation logistics community can 


expand upon. 
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This chapter described the methodology, experimental design, and test metrics of 
the usability study that was accomplished on the MAPSS prototype. The results of the 
usability study and its contribution toward improving system effectiveness, efficiency, 
and user satisfaction are also discussed. The development of the MAPSS prototype was a 
challenging and rewarding academic experience; a summary of the experience, 


conclusions and directions for future research are provided in Chapter VII. 
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Vil. SUMMARY, CONCLUSIONS, AND FUTURE RESEARCH 


This chapter summarizes the analysis of MALSP doctrine and the information 
management systems used to execute mission requirements. Conclusions are then drawn 
on the viability of the prototype to optimize multi-level decision-support for deliberate, 
time sensitive, and crisis action planning for tactical—level aviation logistics. Directions 


and opportunities for future research are also discussed. 


The chapter is organized as follows. Section A summarizes where Marine Corps 
Aviation Logistics has been, where it 1s going, and why a web-enabled application is 
needed to support the transformation; Section B discusses the conclusions of this thesis 
research and frames the progress and accomplishments; and Section C provides direction 
for future research with the MAPSS prototype, focusing on improvements and 
refinements that will ultimately to an effective decision support system for the 21° 
century logistics warfighter. 


A. SUMMARY 


This thesis analyzed the principles and concepts of Marine Aviation Logistics 
doctrine at the tactical-level and the current information management systems used to 
execute mission requirements. The Marine Aviation Logistics community is currently 
undergoing a multi-year doctrinal transformation from MALSP to MALSP-II. Although 
current MALSP doctrine has served the community well for over 20 years, a new 
strategic landscape has emerged which requires more flexibility in developing and 
deploying aviation logistics support forces and equipment. Small-scale contingencies 
have become the norm not the exception; therefore, the Marine Corps must refocus it 
aviation logistics support concepts from “‘standard-sized” to “right-sized” support 


packages. 


Executing aviation logistical operations will require a robust decision support 
system to effectively leverage the concepts of MALSP-II. The current IT architecture for 
planning and sustaining deployed forces and equipment are sufficient, but not the IT 
enabler and force multiplier needed for the twenty-first century battlefield. To mitigate 


the shortcomings of currently fielded systems, MALS planners use flat-file technology 
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that requires extensive resources and the expenditure of valuable man-hours. The lack of 
system integration and the need for a web-centric application was validated by formal 
surveys that were distributed throughout the Marine Corps, and identified as an “action- 
item” from a conference attended by key aviation logistics planners from the Marine 
Corps’ operating forces. The purpose of this thesis was to develop a web-enabled 


prototype to fill the current and projected technology gap that was identified. 


This thesis used the RAD methodology to develop the Marine Aviation Planning 
and Sustainment System (MAPSS), a prototype designed to optimize management and 
decision support for deliberate, time sensitive, and crisis-action planning at the tactical- 
level. Prototyping was an appropriate system development methodology because of the 
current and on-going transformation of Marine Aviation Logistics; it allowed known 
system requirements to be designed and implemented with the first iteration, and allows 
new and unforeseen requirements to be implemented in the future. Microsoft Access 
2003, Microsoft Visio 2003, and Macromedia Dreamweaver MX 2004 were the tools 
used to develop the prototype. The back-end relational database was designed with 
Microsoft Access 2003. The front-end web-enabled interface was designed using 
Macromedia Dreamweaver MX 2004. Microsoft Visio 2003 was used to create the 
conceptual data and logical process models for the system. The first iteration of the 
prototype was subjected to a usability study conducted at the Naval Postgraduate School, 
and also tested by Operations Officers that were assigned to MALS-11 and MALS-36, 
both of which provided valuable feedback. 

B. CONCLUSIONS 


MAPSS is a viable prototype that has the potential to optimize multi-level 
decision support for deliberate, time sensitive, and crisis action planning for aviation 
logistics. The MAPSS prototype consists of over 130 web-pages, all consistently 
designed and logically integrated within three system modules: CONOPS Development, 
COA Development, and Operation Dashboard. The navigational structure of the three 
modules was designed to be consistent with the natural workflow of the current planning 
and sustaining processes of MALS. Furthermore, the use of templates and cascading 
style sheets were instrumental in the development of the unified “look and feel” of the 


prototype. 
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The first version of the prototype was favorably received by both squadrons that 
agreed to “test-drive” the system. The most significant aspect of the system was the four- 
into-one system integration design; MAPSS combined the data sets from four different 
systems into one logically organized user interface. Another important distinction was 
the low-bandwidth design. The text-based system allows users to quickly complete 
transactions, circumventing the bandwidth constraints that normally plague deployed 
forces. The prototype also received positive feedback for its ease of navigation, COA 


comparison techniques, and use of the stoplight model on the Operation Dashboard. 


The MAPSS prototype was also subjected to a usability study, which consisted of 
five participants performing scenario-based tasks. The usability study was an opportunity 
to evaluate the effectiveness, efficiency, and satisfaction with which specified users can 
achieve specified goals. In short, it was opportunity to test the prototype in a controlled 
environment, and the results used to improve the next iteration of the prototype. The 
results for system effectiveness were very encouraging; all participants of the study were 
able to successfully complete all scenario-based tasks. Moreover, the usability study was 
completed with just a 1% system error rate; very acceptable for a first version prototype. 
System efficiency was another important aspect of the study. Collecting the time and 
number of mouse-clicks were instrumental in identifying three potential issues related to 
the navigational side-bar located on each main page of the system. Lastly, user 
satisfaction was determined by a post-experiment survey that measured the level of 
satisfaction with system functionality and usability features. The results were 
overwhelmingly positive: the average score for system functionality was 3.59 and system 
usability received a score of 3.40, both scores were from a 4.00 rating scale. Clearly, 
users were “satisfied” with the first version of the prototype. 


C. FUTURE RESEARCH 


There are multiple avenues of research that can be pursued as a result of this 
thesis that would contribute to the overarching goal: a fielded information management 
system that optimizes decision support for deliberate, time sensitive and crisis action 
planning for tactical-level aviation logistics forces. The most immediate opportunity is to 
continue the evolutionary process of the prototyping methodology; the current prototype 


must be refined and a second iteration developed and deployed. 
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Although MAPSS is a viable concept and was well received, there were numerous 
issues identified that have the potential to make the system more effective and user- 


friendly. The following are some areas that should be researched: 


® Ability to assign multiple personnel, repair parts, support equipment and 
mobile facilities to multiple COAs with one user input transaction. This functionality 
would require complex Structured Query Language (SQL) statements to be coded for the 


COA Development page. 


e Ability for the system to automatically generate a COA shell or template 
(personnel, parts, support equipment and mobile facilities) based on user input of the 
CONOPS Development page. This functionality would require a complex algorithm and 


some statistical analysis of past operations. 


e Optimizing the user interface for both 1024 x 768 and 1280 x 768 
resolution monitors and designing a fourth module (System Administration) with future 


prototype iterations. 


Another essential area that needs to be addressed is the back-end data interface 
with existing information management systems. The current version of MAPSS (given 
the scope of one thesis) admittedly only addresses half of the problem domain. This 
thesis was primarily focused on how data from existing systems could be integrated and 
logically organized into one user interface that was conducive to AVLOG planner’s 
needs and requirements. Hence, future research needs to address the other half of the 
problem domain: the physical data link connection of MAPSS with the NALCOMIS, 
MCTFES, SERMIS, TBA and MDSS-II back-end databases. The need to push and pull 
data from existing systems is a basic system requirement for any future AVLOG decision 
support system. The current processes are time consuming and manually intensive. 
Planning logistics support and sustaining deployed forces would only be improved by an 


efficient and interoperable four-into-one web-enabled user interface. 


The last area of research for a system of this nature is database security. MAPSS 
is an operational planning system; hence, it inherently contains sensitive information that 
should be protected against unauthorized disclosure. The web-centricity of the 


application increases the effectiveness and convenience, but it equally increases the risks 
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and vulnerabilities. Database security is a never-ending process, constantly requiring the 
implementation of the latest tactics and techniques to safeguard the confidentiality, 
integrity, and availability of an organization’s information. Future research in this area 
could include the analysis of authentication and accreditation techniques for DoD web- 
enabled databases. Furthermore, vulnerability and penetration testing of the current 
MAPSS database could accomplished, with the intent of improving and strengthening the 
security measures for future iterations of the prototype. The 21“ century battlefield will 
require a robust decision support system to execute mission requirements. Such a system 


is meaningless, however, without equally robust information security measures. 
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